ข้อมูลหลักก่อนขึ้น ERP: ใครเป็นเจ้าของรหัสสินค้า ผู้ขาย และลูกค้าก่อนวัน cutover

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

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

แหล่งที่เราใช้ และสิ่งที่มันบอก

แหล่งแรกคือบทความของสำนักพิมพ์ SAP Press ชื่อ What are the data migration phases for an SAP S/4HANA project (ดูบทความของ SAP Press) เราเปิดอ่านหน้านี้เอง ข้อควรระวังคือมันเป็นบล็อกของสำนักพิมพ์ จึงจัดเป็นแหล่งรอง และหน้าเว็บไม่แสดงวันที่เผยแพร่ ข้อความที่เกี่ยวข้องมีดังนี้

• การล้างข้อมูล (data cleansing) เป็นหนึ่งในกิจกรรมที่ถูกประเมินต่ำที่สุดในงานย้ายข้อมูล และควรเริ่มให้เร็วที่สุดเท่าที่ทำได้ในโครงการ

• การล้างข้อมูลควรเสร็จอย่างช้าที่สุดพร้อมกับการโหลดทดสอบรอบสุดท้ายที่ใช้ข้อมูลจริง (last productive load test)

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

• เวลาที่ดีที่สุดในการกำหนดกฎตรวจสอบ (validation rules) คือตอนกำหนดกฎการแปลงข้อมูล

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

บทความนั้นเขียนถึง SAP S/4HANA โดยเฉพาะ เราไม่ได้บอกว่าผลิตภัณฑ์ของคุณคือ SAP แต่หลักการที่ระบุ คือเริ่มล้างข้อมูลแต่เนิ่น ๆ ล้างที่ต้นทาง และเขียนกฎตรวจสอบพร้อมกฎแปลง เป็นหลักที่ใช้กับระบบ ERP ตัวอื่นได้ในความเห็นของเรา และเป็นความเห็นของเรา ไม่ใช่ข้อความที่บทความนั้นกล่าวถึงระบบอื่น

แหล่งที่สองคือรายงาน GAO-12-134 ของสำนักงานตรวจเงินแผ่นดินสหรัฐฯ (GAO) เผยแพร่เมื่อวันที่ 28 กุมภาพันธ์ 2012 ว่าด้วยโครงการ ERP ของกองทัพบกและกองทัพอากาศสหรัฐฯ (ดูหน้ารายงานของ GAO) สรุปของรายงานระบุว่าการประเมินอิสระของระบบ ERP สี่ระบบพบข้อบกพร่องด้านความถูกต้องของข้อมูล และผู้ใช้ต้องพึ่งวิธีแก้ขัดที่ทำด้วยมือ นอกจากนี้ ข้อมูลใบแจ้งหนี้และใบรับของราวสองในสามต้องถูกป้อนด้วยมือในระบบหนึ่ง เพราะปัญหาการเชื่อมต่อกับระบบรับ-ส่งของ

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

ข้อมูลหลักคืออะไร และทำไมความเสียหายจึงลามไปทุกที่

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

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

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

กำหนดเจ้าของข้อมูลทีละประเภทก่อน

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

เราแนะนำให้ทำตารางหนึ่งหน้าที่มีหนึ่งแถวต่อข้อมูลหลักหนึ่งประเภท แล้วตอบห้าข้อ ได้แก่

• ประเภทข้อมูล เช่น รายการสินค้า ผู้ขาย ลูกค้า ผังบัญชี หน่วยนับ คลังสินค้า

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

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

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

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

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

ล้างที่ระบบต้นทาง ไม่ใช่ที่ปลายทาง

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

การล้างที่ต้นทางทำได้เป็นขั้น เรียงจากงานที่เสี่ยงต่ำไปสูง

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

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

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

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

เขียนกฎตรวจสอบพร้อมกฎแปลงข้อมูล

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

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

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

เรื่องการตรวจสอบหลังย้ายและการ cutover โดยทั่วไป เราเขียนไว้แล้วในบทความเรื่อง validate และ cutover ตอนเปลี่ยนระบบ ส่วนบทความนี้เน้นที่ข้อมูลหลักและคนที่เป็นเจ้าของมัน

ซ้อมโหลดจนผลนิ่ง และสิ่งที่ควรขอให้ผู้พัฒนาแสดงก่อนวัน cutover

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

ในการซ้อมแต่ละรอบ เราแนะนำให้ขอให้ผู้พัฒนาหรือผู้ให้บริการแสดงสิ่งต่อไปนี้ เป็นเอกสารหรือการสาธิต ไม่ใช่คำบอกเล่า

1. รายงานผลการตรวจก่อนย้ายและหลังย้าย แยกตามประเภทข้อมูลหลัก พร้อมจำนวนรายการที่ผ่านและไม่ผ่านต่อกฎแต่ละข้อ

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

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

4. บันทึกว่าแต่ละรอบเปลี่ยนอะไร เพื่อเทียบได้ว่ารอบนี้ผลดีขึ้นเพราะข้อมูลสะอาดขึ้น หรือเพราะกฎเปลี่ยน

5. แผนสำหรับรายการที่ยังผิดอยู่ ณ วัน cutover ว่าจะมีใครแก้ ภายในกี่วัน และระหว่างนั้นระบบป้องกันไม่ให้ใช้รายการนั้นอย่างไร

ข้อกำหนดเหล่านี้ควรเขียนไว้ใน TOR หรือสัญญาตั้งแต่ต้น เพื่อไม่ให้กลายเป็นเรื่องต่อรองตอนใกล้ส่งมอบ เราเขียนแนวทางการใส่เงื่อนไขที่ทำให้ระบบดูแลต่อได้ไว้ในบทความเรื่องเงื่อนไขใน TOR ซึ่งใช้กับเรื่องนี้ได้

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

เรื่องที่ไม่ควรทำ

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

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

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

จะเริ่มตรงไหน

1. ทำตารางข้อมูลหลักหนึ่งหน้า ใส่ประเภทข้อมูล เจ้าของ ระบบต้นทาง กฎการซ้ำ และกฎตรวจสอบ แล้วให้ผู้อนุมัติโครงการตั้งชื่อเจ้าของในแถวที่ยังว่าง

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

3. เริ่มล้างที่ต้นทางตั้งแต่ก่อนโหลดรอบแรก ให้เจ้าของข้อมูลแก้รายการที่ผิดชัดเจนก่อน แล้วค่อยตัดสินรายการที่น่าจะซ้ำ

4. เขียนกฎตรวจสอบคู่กับกฎแปลง ในเอกสารเดียวกัน และให้เจ้าของข้อมูลอ่านและลงชื่อรับรู้

5. กำหนดจำนวนรอบซ้อมโหลดและเกณฑ์ผ่านล่วงหน้า รวมถึงการรันกระบวนการจริงบนข้อมูลที่โหลด และบันทึกผลแต่ละรอบไว้เทียบกัน

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

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส