สรุปสั้น ๆ (TL;DR)
- ERP ย่อมาจาก Enterprise Resource Planning พัฒนามาจากซอฟต์แวร์ MRP ที่โรงงานใช้วางแผนวัตถุดิบในทศวรรษ 1960 และ 1970 และได้ชื่อปัจจุบันในทศวรรษ 1990
- ERP ส่วนใหญ่ครอบคลุมงานหลักห้าด้าน คือ บัญชีและการเงิน คลังสินค้า จัดซื้อ คำสั่งขาย และบุคคลกับเงินเดือน โดยมักทยอยเปิดใช้เป็นเฟสและเริ่มจากการเงินก่อน
- CRM เป็นเจ้าของลีด ผู้ติดต่อ และ pipeline ส่วน ERP เป็นเจ้าของคำสั่งซื้อ สต็อก ใบแจ้งหนี้ และการชำระเงิน สองระบบบรรจบกันที่ใบเสนอราคาหรือคำสั่งขาย และแต่ละฟิลด์ต้องมีระบบเจ้าของเพียงระบบเดียว
- กรมสรรพากรมีระบบ e-Tax Invoice & e-Receipt จึงควรตรวจสอบว่า ERP ออกเอกสารภาษีอิเล็กทรอนิกส์ได้ และสร้างรายงานประกอบแบบ ภ.พ.30 รายเดือนได้
- ความล้มเหลวของ ERP ที่พบบ่อยที่สุดคือข้อมูลหลักไม่สะอาด การปรับแต่งเพื่อสร้างทางลัดแบบเดิมขึ้นใหม่ และการปล่อยงานเชื่อม CRM กับมาร์เก็ตเพลสไว้จนสัปดาห์สุดท้าย
ERP คือ ซอฟต์แวร์ที่ใช้บริหารงานหลังบ้านหลักของบริษัท เช่น บัญชี คลังสินค้า จัดซื้อ คำสั่งขาย และงานบุคคล บนฐานข้อมูลเดียวกัน ธุรกรรมหนึ่งรายการจึงอัปเดตทุกแผนกที่เกี่ยวข้องพร้อมกัน ในทางปฏิบัติ คำสั่งขายที่บันทึกเข้า ERP ครั้งเดียวสามารถจองสต็อก สร้างใบขอซื้อ ลงรายได้ในบัญชีแยกประเภท และแสดงในรายงานผู้บริหารได้โดยไม่มีใครต้องพิมพ์ซ้ำ บทความนี้อธิบายว่า ERP ย่อมาจากอะไร มีโมดูลอะไรบ้าง ข้อมูลไหลระหว่างโมดูลอย่างไร ERP ต่างจาก CRM ตรงไหน ทำไมควรเชื่อมกับ CRM และช่องทางขายออนไลน์ cloud กับ on-premise ต่างกันอย่างไร และจะเริ่มใช้อย่างไรให้เลี่ยงความผิดพลาดที่พบบ่อย
ERP ย่อมาจากอะไร
ERP ย่อมาจาก Enterprise Resource Planning หรือการวางแผนทรัพยากรองค์กร ชื่อนี้มีรากมาจากโรงงานอุตสาหกรรม ในทศวรรษ 1960 และ 1970 โรงงานใช้ซอฟต์แวร์ MRP (Material Requirements Planning) คำนวณว่าต้องสั่งวัตถุดิบอะไรและสั่งเมื่อไร ต่อมา MRP II เพิ่มการวางแผนกำลังการผลิตและการควบคุมหน้างาน เมื่อผู้พัฒนาขยายแนวคิดเดียวกันไปถึงงานการเงิน บุคคล การขาย และการกระจายสินค้าในทศวรรษ 1990 ผลิตภัณฑ์ที่ครอบคลุมกว้างขึ้นนี้จึงถูกเรียกว่า ERP
คำว่า "planning" ในปัจจุบันชวนให้เข้าใจผิดอยู่บ้าง ERP ยุคนี้ส่วนใหญ่ทำหน้าที่เป็นระบบบันทึกหลัก (system of record) คือเก็บธุรกรรมฉบับทางการ เช่น ใบแจ้งหนี้ ใบเสร็จ การเคลื่อนไหวของสต็อก และรอบการจ่ายเงินเดือน พร้อมบังคับใช้กฎที่เกี่ยวข้อง เช่น วงเงินอนุมัติ วิธีคิดต้นทุน และการรันเลขที่เอกสาร ฟีเจอร์ด้านการวางแผนอย่างการพยากรณ์ความต้องการ การจัดตารางผลิต และการทำงบประมาณยังมีอยู่ แต่หลายบริษัทใช้ ERP เป็นอันดับแรกในฐานะที่ที่ตัวเลขกลายเป็นตัวเลขทางการของบริษัท
หัวใจของ ERP คือฐานข้อมูลร่วม ก่อนมี ERP บริษัทหนึ่งอาจใช้โปรแกรมบัญชีแยกต่างหาก ใช้สเปรดชีตคุมสต็อก และใช้อีกเครื่องมือหนึ่งทำเงินเดือน แต่ละระบบเก็บข้อมูลลูกค้า สินค้า และพนักงานคนละชุด พอถึงสิ้นเดือนก็ต้องนั่งกระทบยอดด้วยมือ ERP แทนที่สำเนาเหล่านั้นด้วยข้อมูลหลักชุดเดียวต่อลูกค้า สินค้า ผู้ขาย และพนักงานแต่ละราย
โมดูลหลักของ ERP มีอะไรบ้าง
ผู้พัฒนาแต่ละรายจัดแพ็กเกจโมดูลต่างกัน แต่ ERP ส่วนใหญ่ครอบคลุมงานห้าด้านเดียวกัน และแทบไม่มีบริษัทไหนเปิดใช้ทุกโมดูลพร้อมกันตั้งแต่วันแรก
บัญชีและการเงิน
ได้แก่ บัญชีแยกประเภททั่วไป ลูกหนี้ เจ้าหนี้ การกระทบยอดธนาคาร สินทรัพย์ถาวร และรายงานการเงิน ทุกโมดูลอื่นจะลงรายการบัญชีมาที่นี่ในที่สุด โมดูลการเงินจึงมักขึ้นระบบเป็นโมดูลแรก และผังบัญชีต้องออกแบบอย่างรอบคอบตั้งแต่ต้น
คลังสินค้า
ได้แก่ จำนวนสต็อกแยกตามคลัง การติดตามล็อตหรือหมายเลขซีเรียล การโอนย้ายสินค้า การตรวจนับ และวิธีคิดต้นทุน เช่น FIFO หรือต้นทุนถัวเฉลี่ย คลังสินค้าคือจุดที่ออเดอร์จากเว็บไซต์และมาร์เก็ตเพลสทำให้ตัวเลขเพี้ยนบ่อยที่สุด เพราะแต่ละช่องทางตัดสต็อกแยกกันถ้าระบบไม่ได้เชื่อมถึงกัน
จัดซื้อ
ได้แก่ ใบขอซื้อ การอนุมัติ ใบสั่งซื้อ การรับสินค้า และการจับคู่ใบแจ้งหนี้ของผู้ขายกับสิ่งที่สั่งและสิ่งที่รับจริง ซึ่งเรียกว่า three-way match กฎการสั่งซื้อซ้ำสามารถสร้างร่างใบสั่งซื้อให้อัตโนมัติเมื่อสต็อกต่ำกว่าจุดขั้นต่ำที่ตั้งไว้
การขายและการจัดการคำสั่งซื้อ
ได้แก่ ใบเสนอราคา คำสั่งขาย ใบส่งของ การออกใบแจ้งหนี้ และการรับคืนสินค้า รายการราคา ส่วนลด และวงเงินเครดิตของลูกค้าอยู่ในโมดูลนี้ ซึ่งเป็นส่วนที่ ERP กับ CRM ทับซ้อนกันมากที่สุด จะอธิบายในหัวข้อถัดไป
บุคคลและเงินเดือน
ได้แก่ ประวัติพนักงาน วันลา การลงเวลา การคำนวณเงินเดือน และรายการหักตามกฎหมาย ในไทยรวมถึงเงินสมทบประกันสังคมและภาษีเงินได้บุคคลธรรมดาที่หัก ณ ที่จ่าย ผลลัพธ์จากระบบเงินเดือนต้องตรงกับข้อมูลที่บริษัทยื่นต่อหน่วยงานรัฐ
หลายระบบมีโมดูลเสริม เช่น การผลิต (สูตรการผลิตและใบสั่งผลิต) บัญชีโครงการ งานบริการภาคสนาม หรือระบบหน้าร้าน (POS) หลักที่ใช้ได้จริงคือ ซื้อตามโมดูลที่ต้องใช้ในสองปีข้างหน้า และตรวจสอบว่าโมดูลที่เหลือเพิ่มภายหลังได้โดยไม่ต้องติดตั้งใหม่ทั้งระบบ
ข้อมูลไหลผ่าน ERP อย่างไร
คุณค่าของ ERP เห็นชัดเมื่อไล่ตามธุรกรรมหนึ่งรายการข้ามโมดูล ต่อไปนี้คือตัวอย่างสมมติของกระบวนการ order-to-cash ตั้งแต่รับออเดอร์จนรับเงิน ของบริษัทที่ขายเครื่องฟอกอากาศ:
- พนักงานขายยืนยันใบเสนอราคา 20 เครื่อง แล้วใบเสนอราคานั้นกลายเป็นคำสั่งขาย
- โมดูลคลังจอง 20 เครื่องจากคลังกรุงเทพฯ ถ้ามีของเพียง 12 เครื่อง กฎการสั่งซื้อซ้ำจะสร้างร่างใบขอซื้อสำหรับส่วนที่ขาด
- ฝ่ายจัดซื้ออนุมัติใบขอซื้อและส่งใบสั่งซื้อให้ผู้ขาย เมื่อสินค้ามาถึง การรับสินค้าจะเพิ่มสต็อกและบันทึกหนี้สินที่รอใบแจ้งหนี้จากผู้ขาย
- คลังหยิบและจัดส่งสินค้า ใบส่งของตัดสต็อกและลงต้นทุนขายในบัญชีแยกประเภทตามต้นทุนที่คำนวณได้ของสินค้านั้น
- ฝ่ายบัญชีออกใบกำกับภาษี รายได้และภาษีขายลงบัญชีแยกประเภทโดยอัตโนมัติ
- เมื่อลูกค้าชำระเงิน รายการในสเตทเมนต์ธนาคารถูกจับคู่กับใบแจ้งหนี้ และยอดลูกหนี้รายการนั้นถูกปิด
ไม่มีใครต้องพิมพ์ออเดอร์ซ้ำ ฝ่ายการเงินเห็นรายได้และกำไรขั้นต้นในวันเดียวกับที่สินค้าออกจากคลัง และฝ่ายจัดซื้อเห็นความต้องการก่อนของจะหมด ตรงข้ามกับการทำงานแบบ "เก้าอี้หมุน" ที่พนักงานคัดลอกออเดอร์จากระบบหนึ่งไปใส่อีกระบบ ทุกครั้งที่คัดลอกคือโอกาสพิมพ์ผิด เกิดความล่าช้า และเกิดยอดไม่ตรงที่จะโผล่มาตอนปิดงบสิ้นเดือน
ERP ต่างจาก CRM อย่างไร
CRM ดูแลความสัมพันธ์ก่อนและระหว่างการขาย เช่น ลีด รายชื่อผู้ติดต่อ โอกาสการขาย ขั้นตอนใน pipeline แคมเปญ และเคสบริการลูกค้า ส่วน ERP ดูแลตัวธุรกรรมและทุกอย่างหลังจากนั้น เช่น คำสั่งซื้อ สต็อก ใบแจ้งหนี้ การชำระเงิน และต้นทุน พูดให้สั้นคือ CRM ตอบคำถามว่า "ใครน่าจะซื้อ และบอกอะไรเขาไปแล้วบ้าง" ส่วน ERP ตอบว่า "ขายอะไรไป ส่งของแล้วหรือยัง และได้รับเงินหรือยัง"
เส้นแบ่งอยู่ที่ใบเสนอราคาหรือคำสั่งซื้อ บางบริษัทสร้างใบเสนอราคาใน CRM แล้วส่งไปที่ ERP เป็นคำสั่งขาย บางบริษัทออกใบเสนอราคาใน ERP แล้วส่งผลกลับไปที่ CRM ทั้งสองแบบใช้ได้ ตราบใดที่กำหนดชัดว่าระบบไหนเป็นเจ้าของข้อมูลแต่ละรายการ เรื่อง CRM มีบทความอธิบายแยกไว้ในบล็อกนี้แล้ว หัวข้อนี้จึงพูดถึงเฉพาะจุดที่สองระบบมาบรรจบกัน
| ประเด็น | ERP | CRM |
|---|---|---|
| ผู้ใช้หลัก | การเงิน คลังสินค้า จัดซื้อ บุคคล | ฝ่ายขาย การตลาด บริการลูกค้า |
| ข้อมูลหลัก | คำสั่งซื้อ สต็อก ใบแจ้งหนี้ การชำระเงิน เงินเดือน | ลีด ผู้ติดต่อ โอกาสการขาย กิจกรรม |
| ผลลัพธ์ที่ได้ | งบการเงิน มูลค่าสต็อก รายงานภาษี | คาดการณ์ยอดใน pipeline ผลแคมเปญ รายการที่ต้องติดตาม |
| สิ่งที่รับมาจากอีกระบบ | คำสั่งซื้อที่ยืนยันแล้วและข้อมูลลูกค้าใหม่ | สถานะใบแจ้งหนี้ สถานะการชำระเงิน และประวัติการสั่งซื้อ |
ทำไมต้องเชื่อม ERP กับ CRM และร้านออนไลน์
ERP รู้เฉพาะยอดขายที่ไหลเข้ามาถึงตัวมันเท่านั้น ถ้าออเดอร์เข้ามาจากเว็บไซต์ ร้านบนมาร์เก็ตเพลส และแชต LINE ด้วย แต่ช่องทางเหล่านั้นไม่ได้เชื่อมกัน ข้อมูลใน ERP ก็จะไม่ครบ และตัวเลขสต็อกจะค่อย ๆ คลาดจากของจริง
ERP กับ CRM
การเชื่อมสองระบบทำให้สถานะใบแจ้งหนี้ ยอดค้างชำระ และประวัติการสั่งซื้อไปอยู่ในหน้าข้อมูลลูกค้าของ CRM พนักงานขายจะไม่รับปากเรื่องสต็อกที่ไม่มีอยู่จริง และไม่ไปทวงเงินลูกค้าที่จ่ายแล้ว ในอีกทิศทางหนึ่ง ดีลที่ปิดได้สามารถสร้างข้อมูลลูกค้าและคำสั่งขายใน ERP ได้โดยไม่ต้องพิมพ์ซ้ำ การซิงก์โดยทั่วไปครอบคลุมข้อมูลหลักของลูกค้า สินค้าและรายการราคา คำสั่งซื้อ และสถานะใบแจ้งหนี้หรือการชำระเงิน
ERP กับอีคอมเมิร์ซและมาร์เก็ตเพลส
สำหรับผู้ขายออนไลน์ จุดเชื่อมที่สำคัญที่สุดคือสต็อก ถ้าสินค้าตัวหนึ่งขายทั้งบนเว็บไซต์ของตัวเองและบนมาร์เก็ตเพลสสองแห่ง ทุกช่องทางต้องเห็นจำนวนพร้อมขายเท่ากัน และทุกออเดอร์ต้องเข้าถึง ERP เพื่อจองสต็อก สร้างใบส่งของ และออกใบแจ้งหนี้ ถ้าไม่มีการเชื่อมนี้ ลูกค้าสองคนอาจซื้อสินค้าชิ้นสุดท้ายในเวลาเดียวกันจากคนละช่องทาง การเชื่อมระบบควรดึงค่าธรรมเนียมและยอดโอนเงินจากมาร์เก็ตเพลสกลับมาที่ฝ่ายการเงินด้วย เพื่อให้กระทบยอดเงินที่ได้รับกับออเดอร์แต่ละรายการได้
ทำไมฝ่ายการตลาดต้องสนใจ
แพลตฟอร์มโฆษณาปรับการแสดงผลตามมูลค่า conversion ที่ส่งเข้าไป เมื่อมูลค่าออเดอร์ การคืนสินค้า และกำไรขั้นต้นมาจาก ERP แทนที่จะมาจากแท็กหน้าเว็บอย่างเดียว ฝ่ายการตลาดจะรายงานรายได้ที่เหลือจริงหลังหักการยกเลิกและการคืนเงินได้ ข้อมูลชุดเดียวกันนี้คือสิ่งที่ทำให้การประมูลโฆษณาตามกำไรเป็นไปได้ในภายหลัง
การเชื่อมระบบทำได้ทั้งผ่านตัวเชื่อมสำเร็จรูป ผ่านมิดเดิลแวร์ที่จับคู่ฟิลด์ระหว่างระบบ หรือเขียน API เอง ไม่ว่าเลือกทางไหน ต้องตัดสินใจก่อนว่าระบบใดเป็นเจ้าของฟิลด์ใด (เช่น ERP เป็นเจ้าของราคาและสต็อก ส่วน CRM เป็นเจ้าของความต้องการในการติดต่อของลูกค้า) และจะจัดการอย่างไรเมื่อทั้งสองฝั่งแก้ข้อมูลรายการเดียวกัน
Cloud ERP กับ On-premise ERP ต่างกันอย่างไร
Cloud ERP โฮสต์โดยผู้พัฒนาหรือพาร์ทเนอร์และใช้งานผ่านเบราว์เซอร์ ส่วนใหญ่คิดค่าบริการแบบสมัครสมาชิก On-premise ERP ทำงานบนเซิร์ฟเวอร์ที่บริษัทควบคุมเอง ในสำนักงานหรือดาต้าเซ็นเตอร์ของตัวเอง การเปรียบเทียบนี้ไม่ได้อยู่ที่ว่าแบบไหนดีกว่า แต่อยู่ที่ว่าใครรับผิดชอบเรื่องอะไร
- ต้นทุนเริ่มต้นกับต้นทุนต่อเนื่อง Cloud ย้ายค่าใช้จ่ายไปเป็นค่าบริการรายงวด On-premise ต้องลงทุนเซิร์ฟเวอร์ ไลเซนส์ และทีมไอทีตั้งแต่ต้น โดยบางรูปแบบไลเซนส์มีค่าใช้จ่ายต่อเนื่องต่ำกว่า
- การอัปเกรด Cloud อัปเดตตามรอบของผู้พัฒนา ทำให้ระบบทันสมัยอยู่เสมอ แต่หน้าจอและการทำงานอาจเปลี่ยนโดยที่ผู้ใช้ไม่ได้เตรียมตัว On-premise อัปเกรดเมื่อบริษัทเลือกเอง ซึ่งในทางปฏิบัติมักถูกเลื่อนออกไปหลายปี
- การปรับแต่ง On-premise มักยอมให้แก้โค้ดได้ลึกกว่า Cloud จำกัดการปรับแต่งไว้ที่การตั้งค่าและจุดขยายที่กำหนดไว้ ความยืดหยุ่นจึงน้อยกว่าแต่การอัปเกรดปลอดภัยกว่า
- ความปลอดภัยและที่ตั้งข้อมูล ผู้ให้บริการ cloud ดูแลความปลอดภัยของโครงสร้างพื้นฐาน แต่บริษัทยังต้องรับผิดชอบสิทธิ์ผู้ใช้ รหัสผ่าน และการกำหนดสิทธิ์เอง ถ้ามีข้อกำหนดว่าข้อมูลต้องเก็บไว้ที่ใด ให้ถามผู้พัฒนาว่าโฮสต์ข้อมูลไว้ที่ไหน
- การเชื่อมระบบ Cloud ERP มักเปิด web API ให้เครื่องมืออีคอมเมิร์ซและ CRM เรียกใช้ได้โดยตรง ส่วนระบบ on-premise รุ่นเก่าอาจต้องมีมิดเดิลแวร์คั่นกลาง
รูปแบบผสม (hybrid) ก็พบได้บ่อย เช่น ใช้ cloud ERP สำหรับการเงินและการขาย และเก็บระบบในเครื่องไว้สำหรับไลน์ผลิตหรือเครื่องมือคลังรุ่นเก่าจนกว่าจะปลดระวางได้
ขั้นตอนเริ่มใช้ ERP และความเสี่ยงที่พบบ่อย
ขั้นตอนการติดตั้งและเริ่มใช้งาน
- เขียนกระบวนการปัจจุบันออกมา บันทึกว่าการรับออเดอร์ การจัดซื้อ การตรวจนับสต็อก และการปิดงบสิ้นเดือนทำงานอย่างไรในวันนี้ รวมถึงทางลัดที่ทำในสเปรดชีต ทางลัดเหล่านั้นคือความต้องการของระบบ
- กำหนดขอบเขตและเจ้าของงาน เลือกโมดูลสำหรับเฟสแรก ตั้งเจ้าของงานฝั่งธุรกิจให้แต่ละโมดูล และตกลงกันว่า "เสร็จ" หมายถึงอะไร เช่น ปิดงบเดือนแรกในระบบใหม่ได้ทั้งหมด
- เลือกระบบ ทดสอบผู้พัฒนาแต่ละรายด้วยสถานการณ์ของบริษัทเอง เช่น การส่งของไม่ครบ การรับคืน การซื้อด้วยเงินตราต่างประเทศ และออเดอร์จากมาร์เก็ตเพลส การเดโมด้วยข้อมูลตัวอย่างของผู้พัฒนาพิสูจน์อะไรได้น้อย
- ออกแบบข้อมูลหลัก ผังบัญชี รหัสสินค้า หน่วยนับ ข้อมูลลูกค้าและผู้ขาย และตำแหน่งคลัง ล้างข้อมูลซ้ำก่อนย้ายเข้าระบบ ไม่ใช่หลังย้าย
- ตั้งค่าและเชื่อมระบบ ตั้งค่าโมดูล กฎการอนุมัติ และแบบฟอร์มเอกสาร จากนั้นสร้างการเชื่อมต่อกับ CRM เว็บไซต์ และมาร์เก็ตเพลส
- ย้ายข้อมูลและทดสอบ นำเข้ายอดยกมาและออเดอร์ที่ยังค้างอยู่ แล้วทดสอบตั้งแต่ต้นจนจบกับผู้ใช้จริงด้วยธุรกรรมที่ใกล้เคียงของจริง
- อบรมและขึ้นระบบจริง อบรมตามบทบาทหน้าที่แทนการอบรมตามโมดูล วางวันเปลี่ยนระบบให้ตรงกับรอบปิดงวด และจัดทีมซัพพอร์ตไว้ในช่วงสัปดาห์แรก ๆ
- ทบทวนหลังขึ้นระบบ เทียบเวลาปิดงบสิ้นเดือน ความแม่นยำของสต็อก และจำนวนออเดอร์ที่ผิดพลาด กับค่าฐานที่บันทึกไว้ในขั้นตอนแรก
ความเสี่ยงที่พบบ่อย
- ลอกกระบวนการเก่าไปใส่ซอฟต์แวร์ใหม่ การสร้างทางลัดแบบเดิมทุกอย่างขึ้นมาใหม่ด้วยการปรับแต่ง ทำให้ต้นทุนสูงขึ้นและอัปเกรดในอนาคตยากขึ้น
- ข้อมูลหลักไม่สะอาด ลูกค้าซ้ำและรหัสสินค้าที่ไม่สม่ำเสมอจะติดเข้าไปในระบบใหม่ทันที และทำให้รายงานผิดตั้งแต่วันแรก
- ขอบเขตงานบานปลาย การเพิ่มโมดูลกลางโครงการทำให้วันขึ้นระบบเลื่อนออกไป ให้พักคำขอใหม่ไว้ในเฟสสอง
- ไม่มีเจ้าของงานภายใน ถ้าโครงการเป็นของฝ่ายไอทีหรือของผู้พัฒนาเพียงฝ่ายเดียว กฎทางธุรกิจจะถูกตัดสินโดยใครก็ตามที่บังเอิญอยู่ในห้องประชุม
- ปล่อยเรื่องเชื่อมระบบไว้ท้ายสุด การเชื่อมช่องทางขายและ CRM ที่เพิ่งทดสอบในสัปดาห์สุดท้าย มักล้มเมื่อเจอปริมาณออเดอร์จริง
- อบรมน้อยเกินไป ผู้ใช้ที่ไม่เชื่อมั่นในระบบจะกลับไปใช้สเปรดชีต แล้วฐานข้อมูลร่วมก็จะไม่ครบอีกต่อไป
ERP กับ e-Tax และภาษีในไทย
สำหรับบริษัทไทย ERP มักเป็นระบบที่ออกเอกสารภาษี จึงต้องรองรับข้อกำหนดในประเทศ กลไกที่ควรตรวจสอบระหว่างเลือกระบบมีดังนี้
- ใบกำกับภาษีและใบรับ กรมสรรพากรมีระบบ e-Tax Invoice & e-Receipt ที่ให้ผู้ประกอบการออกเอกสารเหล่านี้ในรูปแบบอิเล็กทรอนิกส์แทนกระดาษ และมีช่องทาง e-Tax Invoice by Email อีกทางหนึ่ง ให้ถามว่า ERP สร้างเอกสารในรูปแบบอิเล็กทรอนิกส์ที่กำหนดได้เองหรือไม่ หรือต้องใช้ผู้ให้บริการภายนอกช่วยนำส่ง
- รายงานภาษีมูลค่าเพิ่ม ผู้ประกอบการที่จดทะเบียนภาษีมูลค่าเพิ่มยื่นแบบ ภ.พ.30 เป็นรายเดือน โดยมีรายงานภาษีขายและรายงานภาษีซื้อประกอบ ERP ควรสร้างรายงานเหล่านี้จากใบแจ้งหนี้ที่ลงบัญชีแล้ว ไม่ใช่จากสเปรดชีตแยก
- ภาษีหัก ณ ที่จ่าย การจ่ายเงินให้ผู้ขายและผู้ให้บริการหลายกรณีต้องหักภาษี ณ ที่จ่าย และออกหนังสือรับรองการหักภาษี ณ ที่จ่ายให้ผู้รับเงิน ตรวจสอบว่าขั้นตอนจัดซื้อและจ่ายเงินคำนวณยอดและออกหนังสือรับรองได้
- ภาษาไทยและปีพุทธศักราช เอกสารภาษีและรายงานอาจต้องใช้ข้อความภาษาไทยและปฏิทินพุทธศักราช จึงควรทดสอบแบบฟอร์มเอกสารจริง ไม่ใช่ดูแค่หน้าจอ
กฎ รูปแบบ และเงื่อนไขการเข้าร่วมเปลี่ยนแปลงได้ตามเวลา ควรยืนยันข้อกำหนดล่าสุดกับกรมสรรพากรหรือผู้สอบบัญชีก่อนขึ้นระบบ แทนการพึ่งเช็กลิสต์ของผู้พัฒนาเพียงอย่างเดียว
ความหมายสำหรับธุรกิจไทย
SME ไทยจำนวนมากเริ่มจากโปรแกรมบัญชี แล้วเพิ่มการขายออนไลน์ผ่านมาร์เก็ตเพลส โซเชียลคอมเมิร์ซ และ LINE ก่อนจะคิดถึง ERP พอการตรวจนับสต็อกและการกระทบยอดสิ้นเดือนเริ่มเป็นภาระ ออเดอร์ก็กระจายอยู่หลายช่องทางแล้ว ลำดับงานที่ใช้ได้จริงมักเป็นแบบนี้ คือ ทำรหัสสินค้าและข้อมูลลูกค้าให้เป็นมาตรฐาน ตัดสินใจว่าระบบไหนเป็นเจ้าของสต็อก เชื่อมช่องทางขาย แล้วจึงเพิ่มฟีเจอร์ด้านการวางแผน ตัวเลขแรกที่ควรวัดคือจำนวนชั่วโมงต่อเดือนที่ทีมใช้คัดลอกออเดอร์และกระทบยอดสต็อกด้วยมือ เพราะนั่นคือตัวเลขที่โครงการควรลดลงให้ได้
คำถามที่พบบ่อยเกี่ยวกับ ERP
ERP คืออะไร อธิบายแบบง่าย ๆ
ERP คือระบบเดียวที่เก็บข้อมูลบัญชี สต็อก จัดซื้อ คำสั่งขาย และงานบุคคลของบริษัทไว้ในฐานข้อมูลเดียว ธุรกรรมที่บันทึกครั้งเดียวจึงอัปเดตทุกแผนก ระบบนี้มาแทนเครื่องมือและสเปรดชีตหลายตัวที่ต่างคนต่างเก็บสำเนาข้อมูลของตัวเอง
ธุรกิจขนาดเล็กจำเป็นต้องใช้ ERP หรือไม่
ธุรกิจขนาดเล็กจำเป็นต้องใช้ ERP เมื่อการกระทบยอดระหว่างยอดขาย สต็อก และบัญชีด้วยมือเริ่มกินเวลาจริงหรือทำให้เกิดข้อผิดพลาด ไม่ใช่เมื่อมีพนักงานถึงจำนวนใดจำนวนหนึ่ง บริษัทที่ขายสินค้าตัวเดียวผ่านช่องทางเดียวใช้โปรแกรมบัญชีก็เพียงพอ แต่บริษัทที่ขายหลายร้อย SKU ทั้งบนเว็บไซต์และมาร์เก็ตเพลสมักไปต่อไม่ไหว
ERP ใช้แทน CRM ได้หรือไม่
ERP ใช้แทน CRM ได้ในบริษัทขนาดเล็ก เพราะชุด ERP บางตัวมีโมดูล CRM ที่ครอบคลุมรายชื่อผู้ติดต่อและใบเสนอราคาขั้นพื้นฐาน ส่วนทีมขายและการตลาดที่ใหญ่ขึ้นมักใช้ CRM แยกสำหรับงาน pipeline และแคมเปญ แล้วเชื่อมกับ ERP เพื่อดูคำสั่งซื้อและสถานะใบแจ้งหนี้
การติดตั้ง ERP ใช้เวลานานเท่าไร
ไม่มีระยะเวลามาตรฐาน เพราะขึ้นอยู่กับขอบเขตงาน จำนวนโมดูล คุณภาพข้อมูล และจำนวนระบบที่ต้องเชื่อม การทยอยขึ้นระบบเป็นเฟส โดยเริ่มจากการเงินและการขายก่อนแล้วค่อยเพิ่มโมดูลอื่น ช่วยลดความเสี่ยงของโครงการใหญ่ที่ทำทุกอย่างพร้อมกัน
ถ้าข้อมูลออเดอร์ สต็อก และลูกค้าของคุณอยู่คนละระบบ บริการ เชื่อมระบบ ERP และ CRM ช่วยวางแผนและเชื่อมข้อมูลเหล่านั้นเข้าหากัน และบริการ พัฒนาและควบรวมข้อมูล รวมข้อมูลจากช่องทางขาย การเงิน และการตลาดไว้ในชั้นรายงานเดียว สำหรับการเปลี่ยนกระบวนการในวงกว้าง ดู บริการ Digital Transformation และถ้าร้านออนไลน์เป็นส่วนหนึ่งของปัญหา บริการ ออกแบบเว็บไซต์อีคอมเมิร์ซ สร้างร้านที่เชื่อมกับระบบหลังบ้านได้ตั้งแต่เริ่มต้น







