InterCloud

ซอฟต์แวร์องค์กร

รายการตรวจสอบสำหรับการเลือกระบบ ERP

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

เริ่มจากความเหมาะสมกับธุรกิจ

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

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

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

ข้อกำหนดด้านภาษีและกฎหมายในประเทศ

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

  • ใบกำกับภาษี ทั้งแบบเต็มรูปและแบบอย่างย่อตามที่กรมสรรพากรกำหนด พร้อมรายการที่ต้องมีครบถ้วน เลขที่เอกสารเรียงลำดับที่ใช้ซ้ำไม่ได้ และการจัดการใบลดหนี้และใบเพิ่มหนี้ที่อ้างอิงใบกำกับภาษีฉบับเดิมอย่างถูกต้อง
  • ภาษีมูลค่าเพิ่มตามอัตราปัจจุบัน พร้อมแบบแสดงรายการภาษีมูลค่าเพิ่มรายเดือน (ภ.พ.30) และรายงานภาษีซื้อ/ภาษีขายที่กระทบยอดตรงกับบัญชีแยกประเภท รวมถึงภาษีซื้อที่ขอคืนไม่ได้และภาษีมูลค่าเพิ่มจากการใช้บริการจากต่างประเทศ
  • e-Tax Invoice & e-Receipt: การสร้างไฟล์ XML ในรูปแบบที่กรมสรรพากรรับ การลงลายมือชื่อดิจิทัลด้วยใบรับรองอิเล็กทรอนิกส์ การส่งให้ลูกค้า และการนำส่งกรมสรรพากรตามกำหนดรายเดือน หรือการเชื่อมต่อกับผู้ให้บริการที่ได้รับการรับรองซึ่งดำเนินขั้นตอนเหล่านี้แทน
  • ภาษีหัก ณ ที่จ่าย: อัตราที่ถูกต้องตามประเภทการจ่ายเงินและประเภทผู้รับเงิน หนังสือรับรองการหักภาษี ณ ที่จ่าย (50 ทวิ) ที่ออกเมื่อจ่ายเงิน และการยื่นแบบ ภ.ง.ด. 3 และ 53 ที่จัดทำจากหนังสือรับรองเหล่านั้น ระบบจำนวนมากคำนวณภาษีหัก ณ ที่จ่ายตั้งแต่ตอนออกใบแจ้งหนี้และบันทึกผิดงวด
  • การปฏิบัติตามกฎหมายด้านเงินเดือน ในกรณีที่รวมงานทรัพยากรบุคคลไว้ในขอบเขต ได้แก่ การหักภาษีตาม ภ.ง.ด. 1 เงินสมทบประกันสังคมตามเพดานค่าจ้างปัจจุบัน กองทุนสำรองเลี้ยงชีพ และหนังสือรับรอง 50 ทวิ ประจำปีสำหรับพนักงาน
  • ภาษาท้องถิ่นในทุกส่วน: หน้าจอ แม่แบบเอกสาร รูปแบบที่อยู่ รูปแบบปฏิทินบนเอกสารตามกฎหมายเมื่อจำเป็น (วันที่แบบพุทธศักราชในประเทศไทย) และการเรียงลำดับและการค้นหาที่รองรับตัวอักษรได้อย่างถูกต้อง รวมถึงวรรณยุกต์และสระ
  • การคุ้มครองข้อมูลส่วนบุคคล (PDPA): การกำหนดสิทธิ์เข้าถึงข้อมูลส่วนบุคคลตามบทบาท วิธีบันทึกฐานทางกฎหมายในการประมวลผลข้อมูลพนักงานและลูกค้า กฎการเก็บรักษาข้อมูล และความสามารถในการตอบคำขอของเจ้าของข้อมูลส่วนบุคคลโดยไม่ต้องพึ่งนักพัฒนา
  • ร่องรอยการตรวจสอบ: บันทึกว่าใครเปลี่ยนแปลงอะไรและเมื่อใด ทั้งข้อมูลหลักและรายการธุรกรรม จัดเก็บในรูปแบบที่ผู้ตรวจสอบยอมรับ

ต้นทุนการเชื่อมต่อระบบ

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

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

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

การโอนย้ายข้อมูลในฐานะงานแยกต่างหาก

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

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

ตกลงแนวทางการเปลี่ยนระบบกับฝ่ายการเงิน การเริ่มต้นใหม่ ณ ต้นงวดบัญชีด้วยยอดยกมานั้นง่ายกว่าการโอนย้ายประวัติรายการ หากจำเป็นต้องมีประวัติ ให้ตกลงให้ชัดเจนว่ารายงานใดต้องออกได้ตรงกันก่อนลงนามรับรอง

ต้นทุนรวมในการเป็นเจ้าของระบบตลอดห้าปี

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

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

การบริหารการเปลี่ยนแปลง

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

วางแผนการฝึกอบรมตามบทบาทและตามสถานการณ์ ในช่วงใกล้วันเริ่มใช้งานจริง โดยใช้ข้อมูลที่ผู้ใช้งานจะเห็นในระบบจริง กำหนดผู้ใช้งานหลัก (Super-user) ในแต่ละฝ่ายก่อนเริ่มอบรม และให้เวลาพวกเขาทดลองใช้ในระบบทดสอบ (Sandbox) คงระบบเดิมไว้ในโหมดอ่านอย่างเดียวช่วงหนึ่งหลังเปลี่ยนระบบ เพื่อให้ผู้ใช้งานตรวจสอบตัวเลขได้ แล้วจึงปิดระบบในวันที่ประกาศไว้ล่วงหน้า

สุดท้าย หลีกเลี่ยงการสร้างรายงานและหน้าจอเดิมทุกรายการขึ้นใหม่ในระบบใหม่ บางรายการมีขึ้นเพียงเพราะระบบเดิมทำบางอย่างไม่ได้ ซึ่งระบบใหม่ทำได้อยู่แล้ว ให้เวลากระบวนการใหม่หนึ่งไตรมาสก่อนตัดสินว่าสิ่งใดขาดหายไปจริง

รายการตรวจสอบโดยสรุป

ฉบับย่อสำหรับคณะกรรมการกำกับโครงการ

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

ดูสถานการณ์ของคุณเองทำงานบน GlowScale

ทีมงานของเรายินดีสาธิตตามสถานการณ์ของคุณ รวมถึงกรณียกเว้น เมื่อคุณร้องขอ GlowScale คือแพลตฟอร์มบริหารธุรกิจสำหรับองค์กรของเรา ครอบคลุมการเงิน การขาย สินค้าคงคลัง การผลิต ทรัพยากรบุคคล และการจัดซื้อ รวมถึงข้อกำหนดด้านภาษีและกฎหมายในประเทศ ใช้งานได้ทั้งบน Cloud, Private Cloud และแบบ On-premise