โดยหลักการทั่วไปแล้ว ข้อมูลในคลังข้อมูลหรือ data warehouse จะมีลักษณะ non-volatile คือ ไม่มีการเปลี่ยนแปลงไปตามเวลา พอข้อมูลเข้าสู่คลังแล้ว มักจะอยู่ในรูปแบบอย่างนั้นไปตลอด แต่พอเอาเข้าจริง ก็มักจะพบกับความต้องการที่จะเปลี่ยนแปลงข้อมูลในคลังข้อมูลอยู่เสมอ เรียกกันว่า Data Restatement
Data Restatement ที่ผมประสบพบเจออยู่บ่อยๆ มีสองแบบ อย่างแรกเลยคือ transaction restatement ประเภทที่สองเรียกว่า reference data restatement ทั้งสองแบบนี้มีวัตถุประสงค์ที่แตกต่างกัน และต้องการการจัดการที่แตกต่างกันด้วย
Transaction Restatement
เป็นการเปลี่ยนแปลงข้อมูลธุรกรรมที่เกิดขึ้นในอดีต สมมติอย่างเช่น มีข้อมูลยอดขายสินค้า A ไปยังลูกค้า ก. ประจำวันที่ 1 ตุลาคม 52 ข้อมูลแรกสุดที่เข้ามาเก็บในคลังข้อมูลบันทึกได้ว่ายอดขายเป็น 100 บาท ตัวเลข 100 บาทนี้ได้ถูกนำไปเผยแพร่ หรือ publish รวมเข้ากับยอดขายสินค้าอื่นๆ ผู้บริหารอาจจะได้ทำการตัดสินใจอะไรบางอย่างไปเรียบร้อยแล้วเกี่ยวกับข้อมูลตัวนี้ (เช่น สั่งเพิ่มปริมาณการผลิตสินค้า A หรือ สั่งให้ส่วนลดพิเศษลูกค้า ก. ไปเรียบร้อยแล้ว) แต่แล้ว ภายหลังพบว่า ข้อมูลยอดขายที่แท้จริงเป็นแค่ 50 บาท จะเกิดอะไรขึ้น? และระบบคลังข้อมูลหรือระบบ business intelligence ควรจะตอบสนองกับกรณีเช่นนี้อย่างไร?
ประเด็นแรกที่ต้องพิจารณา ก็คือ ลักษณะ transaction restatement ควรจะถูกพิจารณาเป็นกรณียกเว้นพิเศษ เพราะถือเป็นการเปลี่ยนแปลงแก้ไขประวัติศาสตร์ โดยเฉพาะอย่างยิ่ง ถ้าเป็นเรื่องที่เกี่ยวข้องกับเงินๆ ทองๆ หรือเกี่ยวข้องกับผลการประกอบการของบริษัท การยอมให้เกิด transaction restatement โดยไม่มีกระบวนการควบคุมที่ดี อาจมีใครบางคนโดน audit เรียกไปคุย หรือแย่ยิ่งกว่านั้น อาจจะต้องถือว่ามีโทษทางกฎหมายด้วยเลยทีเดียว
ดังนั้นแล้วกระบวนการ transaction restatement ต้องได้รับการอนุมัติเป็นกรณีพิเศษ จากผู้บริหารที่สามารถรับผิดชอบผลทางกฎหมายที่จะตามมาจากการแก้ไขข้อมูลได้
สิ่งที่เราพอจะช่วยได้ ก็คือการออกแบบโครงสร้างข้อมูลใน data warehouse ให้รัดกุม ครอบคุลมกระบวนการทางธุรกิจทั้งหลายทั้งปวง อันเป็นที่มาของการแก้ไข transaction ในอดีต รวมไปถึงการทำงานร่วมกับระบบงานอื่นๆ เช่น SCM หรือ ERP เพื่อสร้างระบบควบคุมที่เหมาะสมด้วยเช่นกัน ตัวอย่างเช่น ลงวิเคราะห์กันดูว่า เพราะสาเหตุใดที่ทำให้ยอดขายซึ่งเคยเป็น 100 บาท เปลี่ยนเป็นแค่ 50 บาทได้? เราอาจจะพบว่า เกิดจากพนักงานคีย์ราคาผิด (ควบคุมผ่าน ERP) หรือคีย์จำนวนสินค้าผิด (ควบคุมผ่านกระบวนการส่งของ) หรืออาจจะเกิดจากการที่สินค้าจัดส่งไปแล้ว แต่ลูกค้าคืนสินค้ากลับมาครึ่งหนึง (แก้ไขโดยการออกแบบฐานข้อมูลที่รองรับการคืนสินค้า) เป็นต้น
เอาไว้คราวหน้ามาคุยให้ฟังเรื่อง reference data restatement ต่อแล้วกันครับ
ใน ระหว่างการเตรียมจัดงานประชุมประจำปีภายในของ IT manager ทั่วเอเชีย ผมเตรียมรายชื่อผู้เข้าร่วมงาน ซึ่งเป็น IT manager ระดับ section manager ขึ้นไปที่มี base location อยู่ใน Asia แล้วก็พบปัญหาหลายประการ ตัวอย่างเช่น
-
มีแหล่งข้อมูลมากกว่า 1 แห่ง
และ ที่สำัคัญ ไม่มีแหล่งไหนเลยที่มีทั้งครบถ้วนและถูกต้อง ผมมีรายชื่อมาจาก 3 แหล่งใหญ่ๆ ส่วนแรกคือ SAP-HR ซึ่งมีฐานข้อมูลไว้สำหรับจ่ายเงินเดือนพนักงาน แหล่งที่สองคือ LDAP ซึ่งมี web ให้สามารถดึงข้อมูลมาได้ เป็นข้อมูล account สำหรับเข้าสู่ระบบต่างๆ และสุดท้ายคือ รายชื่อของผู้เข้าร่วมประชุมเมื่อปีที่แล้ว
-
ข้อมูลย่อยที่กระจัดกระจาย
นอก จากราื่ยชื่อ เรายังต้องการข้อมูลประกอบด้วย อาทิเช่น ชื่อใน passport อีเมล์ เพศ ประเทศที่เป็น base location เชื้อชาติหรือประเทศต้นทาง รวมถึงหน่วยงานที่สังกัด ระดับหรือ band ผมพบว่าจากแต่ละแหล่งข้อมูลที่กล่าวมาข้างต้น ไม่มีแหล่งใดเลยที่มีข้อมูลทุกอย่างครบถ้วน SAP HR มีชื่อใน Passport แต่ไม่เก็บอีเมล์ มี base location (โดยดูจากประเทศที่จ่ายเงินเดือน) แต่ไม่มีเชื้อชาติ ส่วน LDAP มีอีเมล์เป็นหลัก กับหน่วยงานที่สังกัด น่าตลกที่ข้อมูลว่าใครเพศอะไร ต้องหาจากรายชื่อผู้เข้าร่วมประชุมปีที่แล้ว
ในแต่ ละแหล่งข้อมูล ผมพบว่ามีข้อมูลจำนวนหนึ่งซึ่งไม่อัพเดตเสมอ มีการย้ายแผนก (จาก IT ไปเป็น Sales หรือจากแผนกวิจัยตลาดมาทำงาน IT ก็มี) มีการย้ายหน่วยงานเช่น Expat มาจากยุโรปหรืออเมริกา แต่มาประจำในเอเชีย หรือไม่ก็ย้ายกลับ บางส่วนก็ลาออกไปบ้าง และที่เพิ่งถูกโปรโมทขึ้นมาเป็น IT manger ใหม่่ก็มีหลายคน บางทีตัวย้ายกลับไปยุโรปแล้ว แต่เงินเดือนยังรับเป็นของสิงคโปร์อยู่เลย หรือบางคนลาออกไปแล้ว แต่ยังอยู่ใน Payroll เพราะใช้วันหยุดพักร้อน กว่าจะ effective จริงๆ ก็อีก 2 เดือนข้างหน้า
ที่ น่าปวดหัวที่สุดคือ ข้อมูลจำเพาะที่มักจะรู้กันโดยไม่ได้บันทึกไว้ในฐานข้อมูล ในการรวบรวมรายชื่อผู้เข้าร่วมงานครั้งนี้ ผมต้องแยกข้อมูลชื่อจริง อีเมล์ และชื่อที่เป็นที่รู้จักกันทั่วไป (aka - as known as) ออกเป็น 3 ส่วน เพราะมันไม่ตรงกัน และสร้างความปวดหัวให้มาก คนที่เรารู้จักอาจจะมีอีเมล์หรือชื่อจริงแตกต่างไปจนจำไม่ได้ อาทิ
- คนญี่ีปุ่นเรามักจะเรียกด้วยนามสกุลเสมอ และบางทีก็เดาไม่ได้ด้วยว่าโคทาโร่ซังที่เราเรียกๆ กันอยู่นี่เป็นผู้หญิงหรือผู้ชาย
- คนจีนทุกคนจะตั้งชื่ออังกฤษของตัวเอง ซึ่งแทบไม่มีส่วนเกี่ยวข้องอะไรเลยกับชื่อจริง แถมนามสกุลออกเสียงคล้ายกันแต่สะกดต่างกันมาก
- ชาว อินเดียเป็นจำนวนมาก มีนามสกุลว่า singh เพื่อนผมคนหนึ่งมี อีเมล์เป็น singh.s.14 หมายความว่าเขาเป็นคนที่นามสกุล singh ชื่อต้นขึ้นด้วย s และมีคนลักษณะอย่างนี้มาก่อนหน้านี้แล้ว 13 คน
- ชาวเกาหลีกับชาวฟิลิปปินส์ มักใช้ชื่อย่อ ซึ่งอาจจะเป็น initials หรือพยางค์ใดพยางค์หนึ่งของชื่อ
- ชาวไทยก็เรียกกันด้วยชื่อเล่นเป็นหลัก เพราะทั้งชื่อจริง นามสกุลจริง ยาวพอๆ กัน ตัดปัญหาเลยบอกชาวบ้านให้เรียกเราในชื่อเล่น
จากปัญหาหลายอย่างที่กล่าวมา วิธีการที่ practical ที่สุดก็คือดึงรายชื่อจากแต่ละแหล่ง แล้วก็มารวมกันเอาโดยอาศัย personal knowledge โชคดีหน่อยที่รายชื่อคนมีไม่มากนัก แค่ไม่เกิน 100 คน แต่จำเป็นต้องใช้ network ของแต่ละองค์กร คือ IM ไปถามจากคนที่เรารู้จัก “รู้มั้ยคนนี้คือใคร?” หรือ “คนนี้ได้ข่าวว่าลาออกไปแล้ว จริงหรือเปล่า” แล้วก็มา cross reference ในแต่ละระบบด้วยตัวเองอีกที แถมงานแบบนี้จะให้น้องๆ admin ทำก็จะใช้เวลาเยอะไปหน่อย เพราะไม่ได้คลุกคลีทำงานด้วยกันกับ IT manager อื่นๆ แถมยังมีความเสี่ยงเรื่องการรักษาความลับด้วย โดยเฉพาะข้อมูลการโยกย้ายหรือปรับตำแหน่งของแต่ละคน
ปรากฎว่าผมใช้เวลาไปประมาณ 3-4 ชม. ในการรวบรวมและจัดการรายชื่อของคนแค่ 100 คน ซึ่งน่าจะใช้เวลาจริงๆ แค่ 3-4 นาที ถ้าเรามีระบบ master data management ที่มีประสิทธิภาพมากกว่านี้
ตัวอย่างนี้อาจจะพอทำให้เห็นภาพได้บ้างว่าปัญหาคุณภาพของข้อมูลอ้างอิง ส่งผลอย่างไรต่อประสิทธิภาพการทำงานในบริษัท ลองนึกภาพดูบ้างว่า แทนที่จะเป็นรายชื่อพนักงาน ถ้าเป็นรายชื่อลูกค้าที่เราต้องติดต่อด้วยเป็นประจำ และมีปริมาณมากกว่านี้ การตัดสินใจลงทุนทางด้าน MDM (ไม่เฉพาะแค่ระบบ แต่รวมไปถึงขั้นตอนกระบวนการในการควบคุมคุณภาพข้อมูลด้วย) น่าจะเป็นทางเลือกหนึ่งที่เพิ่มศักยภาพทางการแข่งขันได้มาก