โดยหลักการทั่วไปแล้ว ข้อมูลในคลังข้อมูลหรือ 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 ต่อแล้วกันครับ