BzInsight

เรื่อง MDM หรือ master data management กำลังเป็นคำยอดฮิตในหมู่คนที่มีส่วนเกี่ยวข้องกับงาน BI แต่ก็เหมือนกันกับ buzzword อื่นๆ ที่พอมีคนพูดถึงกันมากๆ vendor หรือคนไอทีหลายๆ คนก็เริ่มพยายามตั้งชื่อระบบ หรือสร้างงานที่มันมีคำว่า MDM อยู่ด้วย จะได้ไม่ตกยุค

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

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

ผมมี white paper อยู่ฉบับหนึ่ง ซึ่งดาวน์โหลดมาจากไหนก็จำไม่ได้แล้ว แต่เคยเอาเนื้อหาในนั้นมาทำ presentation อธิบายลำดับขั้นความก้าวหน้าในการจัดการข้อมูลอ้างอิงภายในองค์กร เลยตัดเอาเฉพาะส่วนที่อธิบาย maturity level มาอัพขึ้น slideshare ข้างล่าง (อาจจะดูห้วนๆ ไปบ้างนะครับ เพราะความจริงแล้ว section นี้มันฝังอยู่ใน presentation ใหญ่เรื่องอื่ีนอีกที) ส่วนใครสนใจอยากอ่าน white paper ฉบับเต็ม ก็ดาวน์โหลดได้ที่นี่เลยครับ (pdf, Eng, 760kb)

เมื่อประมาณเดือนเมษา 2008 ทาง Information Difference ได้จัดการสำรวจบริษัทต่างๆ รวม 112 แห่ง เกี่ยวกับการนำซอฟต์แวร์ MDM (Master Data Management) ไปใช้ในองค์กรธุรกิจ โดยมีประเด็นคำถามที่สำคัญดังนี้

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

ในบรรดากลุ่มบริษัทที่เข้าร่วมการสำรวจทั้ง 112 บริษัท กว่าครึ่งอยู่ในอเมริกาเหนือ หนึ่งในสี่อยู่ในยุโรป (คลิ้กที่ภาพเพื่อขยาย) ครอบคลุมหลายภาคธุรกิจ

และมากกว่าครึ่งที่มีขนาดของธุรกิจมากกว่า 1 พันล้านเหรียญสหรัฐนับตามยอดขาย

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

ในองค์กรส่วนใหญ่ที่สำรวจ จะมีระบบ IT ที่ซับซ้อนหลากหลาย ทั้ง ERP, CRM และ data warehouse ทำให้เกิดความซ้ำซ้อนของข้อมูลอ้างอิง หลายครั้งที่ข้อมูลอ้างอิงเดียวกัน แต่มีนิยามหรือมาตรฐานข้อมูลที่แตกต่างกันในแต่ละระบบ IT ทำให้การจัดการข้อมูลอ้างอิงเป็นปัญหาสำคัญอยู่ในแทบจะทุกองค์กร

ลักษณะอาการเหล่านี้แสดงให้เห็นว่า ระบบสารสนเทศภายในบริษัท กำลังประสบปัญหาเกี่ยวกับข้อมูลอ้างอิง อาทิเช่น

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

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

ความต้องการขององค์กรต่างๆ ที่คาดหวังให้ระบบ MDM ช่วยจัดการให้ เรียงตามลำดับสูงสุดสามลำดับแรกคือ

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

ส่วนความต้องการด้านอื่นๆ ก็มีลดหลั่นกันไป

อีกหนึ่งคำถามที่น่าสนใจคือ สถาปัตยกรรมแบบไหนที่น่าจะเป็นคำตอบสำหรับงาน MDM ระหว่างการแยกฐานข้อมูลกลางแบ่งตามประเภทของข้อมูล เช่น CDI (Customer Data Integration) หรือ PIM (Product Information Management) หรือการเลือกแพลตฟอร์มแบบเดียวที่สามารถรองรับข้อมูลอ้างอิงได้ทุกแบบ โดยส่วนใหญ่แล้ว (กว่าครึ่ง) ก็ยังไม่ทราบคำตอบ

ส่วนแผนการนำ MDM มาใช้ในองค์กร มี 25% ที่ได้ดำำเนินการด้าน MDM ไปเรียบร้อยแล้ว และว่าครึ่งที่กำลังดำเนินการอยู่ ส่วนที่เหลือโดยมากก็กำลังอยู่ในช่วงวางแผน มีเพียงแค่ 2% เท่านั้นที่ไม่มีแผนจะทำ MDM เลย

และท้ายสุด วิธีการ implement MDM เกือบครึ่งที่จะใช้วิธีซื้อระบบสำเร็จรูป

ผลสำรวจในครั้งนี้สอดคล้องกับแนวโน้มเรื่องการนำ MDM มาใช้ในองค์กร ซึ่งเป็นส่วนหนึ่งของแนวโน้มสำคัญในด้าน Business Intelligence มาตั้งแต่เมื่อปี 2007 และยังต่อเนื่องมาในปี 2008 อีกด้วย

ใครสนใจอ่านผลสำรวจฉบับเต็ม เป็น PDF ไฟล์ขนาด 20 หน้า (2MB) ก็ดาวน์โหลดได้เลยครับ

ภาพจาก TDWI ใครสมัครรับจดหมายข่าวจาก TWDI (The Data Warehousing Inistitute) คงได้รับโปสเตอร์ฉบับนี้แล้วนะครับ ใครยังไม่ได้ก็สมัครขอรับ โปสเตอร์ได้ฟรีครับ คลิ้กตามลิงค์ในภาพไปได้เลย แค่ลงทะเบียนกับเขาเสียหน่อย แล้วก็สามารถดาวน์โหลดมาได้เป็นไฟล์ PDF มีสองขนาด คือ ขนาด Letter (8×11) กับขนาดใหญ่ 20×30 นิ้ว เอาไปพิมพ์ปะข้างฝากันได้ตามสะดวก

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

โดยภาพรวมแล้ว MDM จะประกอบด้วยการทำงานร่วมกันระหว่างสามกลุ่มคือ People, Practices, และ Automation

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

• Practices: การนำ MDM ไปใช้งานยังสามารถแบ่งออกเป็นหลายรูปแบบ อาิทิเช่นในระดับปฏิบัติการ การใช้เพื่อการวิเคราะห์และการใช้ในระดับทั่วทั้งองค์กร

• Automation: งาน MDM โดยทั่วไปจะมีความซับซ้อน ดังนั้นการใช้ระบบซอฟต์แวร์อัตโนมัิติเข้ามาช่วยงาน จึงมีความจำเป็น ไม่ว่าจะเป็นส่วนจัดเก็บข้อมูล ส่วนประสานงาน หรือระบบ front-end ที่ช่วยในการจัดการข้อมูลอ้างอิง

คราวนี้ก็มาเจาะกันทีละส่วนก็แล้วกันนะครับ ส่วนแรกคือ

Cross-Functional Collaboration เป็นการทำงานร่วมกันข้ามแผนก โดยเน้นไปที่การทำความตกลงเรื่องนิยามของข้อมูลอ้างอิง และกระบวนการทำงานเกี่ยวกับข้อมูลอ้างอิง ประกอบไปด้วยการมีทีมงานแบบ cross-functional team ประกอบด้วยทั้งฝ่าย business และ IT ต้องมี Organizational structure หรือโครงสร้างองค์กรที่เข้ามารองรับและสนับสนุนการทำงานของทีมนี้ อาจจะอยู่ในรูปของ Governance committee หรือ  center of excellence ก็ได้ ลักษณะการทำงานจะต้องเป็นแบบ Collaboration ในการตกลงนิยามร่วมกันของข้อมูลอ้างอิง รวมไปถึงความเป็นเจ้าของข้อมูลด้วย และส่วนสุดท้ายคือการ Oversight หรือดูแลการเปลี่ยนแปลงเกี่ยวกับนโยบายข้อมูลอ้างอิงภายในองค์กร

Cross-System Implementation เป็นงานในส่วนที่จะต้องมีการปรับเปลี่ยนระบบงาน IT ที่มีอยู่เดิม ให้สอดคล้องและสนับสนุนมาตรฐานข้อมูลอ้างอิงใหม่ที่กำหนดขึ้น ซึ่งรวมไปถึงการจัดการข้อมูลที่มีอยู่เดิม การพัฒนาหรือปรับแก้ระบบบางส่วน การทดสอบการทำงานร่วมกัน หลายองค์กรเลือกวิธีที่ง่ายกว่า โดยการจัดหาระบบแอพลิเคชันเพื่อการจัดการด้าน MDM โดยเฉพาะ องค์ประกอบที่ต้องพิจารณาเปลี่ยนแปลงแก้ไข ประกอบด้วย Data Modeling ซึ่งนอกจากตัวข้อมูลอ้างอิงแล้ว hierarchy หรือวิธีในการสรุปข้อมูลตามลำดับขั้นก็จำเป็นต้องปรับให้สอดคล้องกับมาตรฐานด้วย Meta Data Management ข้อมูลอ้างอิงอาจจะถูกจัดการโดยการใช้เทคโนโลยีของ meta data ได้ Data Quality เป็นเรื่องสำคัญมากสำหรับข้อมูลอ้างอิง ทั้งในแง่ของการสอดคล้องกับมาตรฐานข้อมูล และกระบวนการตรวจสอบคุณภาพ Data Integration ต้องมีการใช้เทคโนโลยี integration เพื่อให้มีข้อมูลอ้างอิงมีการแพร่กระจายไปยังระบบต่างๆ ที่ต้องการใช้งานได้ และท้ายที่สุดคือ Data profiling หรือการจัดทำรูปแบบข้อมูลจะต้องสามารถครอบคลุมในทุกระบบที่เกี่ยวข้อง

Operational MDM หรือระบบจัดการข้อมูลอ้างอิงเพื่อการปฎิบัติงาน นี่เป็นหนึ่งในรูปแบบการใช้งาน MDM คือเพื่อให้กระบวนการทำงานในระดับปฎิบัติการมีความสอดคล้องกัน ในระหว่างระบบแอพลิเคชันพื้นฐานหลายๆ ระบบ (อาทิเช่น ERP, CRM, และ SCM) เนื่องจากนิยามของข้อมูลอ้างอิงเพื่อการปฎิบัติการ มักจะไม่ค่อยเปลี่ยนแปลงบ่อยนัก ทำให้นิยามข้อมูลอ้างอิงใน MDM ก็ไม่ต้องเปลี่ยนแปลงบ่อยเช่นกัน อย่างไรก็ตาม ความเร็วในการทำงานของระบบปฏิบัติการเหล่านี้เป็นแบบ real-time ดังนั้น Operational MDM จึงต้องทำงานในลักษณะั real-time ไปด้วย ระบบงานที่นำ Operational MDM ไปใช้ประกอบไปด้วย CRM and ERP instances ในกรณีที่มี ERP/CRM มากกว่าหนึ่งระบบ MDM จะเป็นส่วนเชื่อมโยงแต่ละระบบเข้าด้วยกัน  SCM Applications โดยเฉพาะอย่างยิ่งข้อมูลผลิตภัณฑ์ที่แตกต่างกันจากผู้ผลิตแต่ละราย การใช้ MDM จะ่ช่วยให้ข้อมูลสินค้าที่แตกต่างกันนั้น มีความสอดคล้องกันได้ Financial Systems การใช้งาน MDM ในระบบบัญชีและการเิงิน จะช่วยให้สามารถปิดงบได้เร็วขึ้นและรายงานการเงินมีความถูกต้องสูงขึ้น และสุดท้ายคือ Independent MDM application ซึ่งถึงแม้จะมีการใช้ใน analytic MDM แต่โดยมากก็มักจะมีการติดตั้งอยู่กับระบบที่เกี่ยวข้องกับระดับปฏิบัติการ

Analytic MDM ระบบจัดการข้อมูลอ้างอิงเพื่อการวิเคราะห์ เป็นอีกรูปแบบหนึ่งของการใช้งาน MDM ซึ่งแต่เดิมก็เป็นส่วนหนึ่งของระบบคลังข้อมูล (data warehouse) มาก่อนแล้ว ความจำเป็นของ MDM เพื่อการวิเคราะห์ข้อมูล จะอยู่ในจุดสมดุลระหว่างความต้องการข้อมูลที่ถูกต้อง และความต้องการวิเคราะห์ข้อมูลในลักษณะที่แตกต่างไปจากเดิม เช่นการ aggregate ข้อมูลต่าง hierarchy นิยามข้อมูลใน Analytic MDM จะเปลี่ยนแปลงไปได้เร็ว ขึ้นอยู่กับความต้องการใช้ หรือโมเดลการวิเคราะห์ที่ต้องการ การใช้งาน Analytic MDM จะพบใน Data warehouse and marts และใน Reporting อีกทั้งยังพบได้มากในการสร้างแอพลิเคชันอย่าง Customer Data Hubs หรือ Product Data Hubs เพื่อสร้างมุมมองที่สมบูรณ์รอบด้านของข้อมูลเกี่ยวกับลูกค้าและสินค้า

Enterprise MDM ระบบจัดการข้อมูลอ้างอิงในระดับองค์กร กำลังเป็นแนวโน้มที่จะทำให้ MDM กลายเป็นส่วนหนึ่งของโครงสร้างพื้นฐานของระบบสารสนเทศภายในองค์กร และเป็นส่วนสำคัญในการเชื่อมโยงการทำงานระหว่างแผนกและระหว่างระบบไอทีต่างๆ รูปแบบการใช้งานจะประกอบไปด้วย Single MDM Infrastructure รูปแบบการใช้งาน Operation MDM และ Analytic MDM มีความแตกต่างกัน จนทำให้ในหลายๆ องค์กร การพยายามที่จะสร้างโครงสร้างพื้นฐานสำหรับ MDM แบบเดียว เพื่อตอบสนองความต้องการทั้งสองส่วน เป็นไปได้ยาก แต่การมี MDM แบบเดียวก็ยังเป็นลักษณะการใช้งานที่เป็นที่ต้องการอยู่เสมอ MDM Application หากโครงสร้างพื้นฐานด้าน MDM มีอยู่แล้ว จะเกิดการใช้งานแอพลิเคชันใหม่ๆ ตามมา อาทิเช่นแอพลิเคชันทีึ่ใช้จัดการข้อมูลสินค้าหรือข้อมูลลูกค้าแบบครบวงจร เป็นต้น Embeded MDM เป็นลักษณะการใช้งาน MDM ในท้ายที่สุดแล้ว ควรจะสามารถสนับสนุน web services หรือ SOA (Service-Oriented Architecture) เพื่อให้บริการด้าน MDM กลายเป็นบริการที่สามารถเรียกใช้ได้จากระบบและแพลตฟอร์มที่หลากหลาย

ส่วนสุดท้าย เป็นองค์ประกอบที่ใช้ประสานแต่ละกลุ่มเข้าด้วยกัน เรียกว่า MDM Automation via software โดยการใช้ซอฟต์แวร์ช่วยการทำงานร่วมกันของส่วนต่างๆ หรือระหว่างสมาชิกในทีมให้เป็นไปโดยอัตโนมัติ ปัจจัยสำคัญประกอบไปด้วย Processes ระบบซอฟต์แวร์ต้องสามารถสนับสนุนกระบวนการทำงานได้ โดยมากมักจะอยู่ในรูปของ work flow แอพลิเคชัน ที่สอดคล้องกับนโยบายการควบคุมข้อมูลอ้างอิง โดยโปรแกรม work flow จะช่วยให้การขอเพิ่ม เปลี่ยนแปลงแก้ไขข้อมูล ผ่านหน่วยงาน และขั้นตอนการอนุมัติต่างๆ ได้อย่างราบรื่น Repositories หรือส่วนเก็บข้อมูล ซึ่งในที่นี้ไม่ได้หมายความถึงแค่ตัวข้อมุลอ้างอิงเท่านั้น แต่ยังหมายรวมถึง เอกสาร นโยบาย โครงสร้างข้อมูล ผังการทำงาน และอื่นๆ อีกมาก Services หรือบริการที่เกี่ยวข้องกับการจัดการข้อมูล  มีความจำเป็นอย่างยิ่งในระบบที่ทำงานข้ามระบบงาน อาทิเช่น บริการตรวจสอบความถูกต้องของข้อมูล บริการแปลงข้อมูลให้ได้มาตรฐาน หรือการจับคู่ข้อมุล เป็นต้น บริการเหล่านี้อาจจะอยู่ในรูปของ API หรืออาจจะเป็น web services ก็ได้

ก่อนเริ่มลงมือทำโครงการ Business Intelligence ใดๆ ก็ตาม สิ่งที่ผมมักจะทำเสมอคือการ “ประเมิน” ความพร้อมของข้อมูลอ้างอิง หรือ master data readiness ที่มีอยู่ภายในองค์กร หรือภายในแหล่งข้อมูลเบื้องต้นก่อนเสมอ ไม่ว่าจะเป็นโปรเจ็คที่ดูเหมือนจะง่ายๆ อย่างเช่น reporting system หรือจะเป็นลักษณะที่ซับซ้อนมากขึ้นอย่างการผสานรวมข้อมูลจากหลายๆ แผนกเข้าด้วยกัน หนึ่งในหัวข้อหลักที่ผมมักจะถามอยู่เสมอคือ ข้อมูลอ้างอิงมีความพร้อมแค่ไหน และจะต้องทำอะไรบ้าง เพื่อให้มีความพร้อมเพียงพอ

สิ่งที่จะต้องรู้ก่อนก็คือ BI solution หรือระบบที่กำลังจะพัฒนา หรือกำลังจะนำมาใช้ มีความต้องการข้อมูลอ้างอิงอะไรบ้าง และอย่างไรบ้าง ผมเรียกส่วนนี้ว่า master data requirements แต่ละระบบงานก็มีความต้องการแตกต่างกันออกไป คนที่น่าจะรู้เรื่องความต้องการเหล่านี้ได้ดีที่สุดคือ คนที่เป็นเจ้าของ solution

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

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

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

ผมมักจะตั้งต้นด้วยคำถามง่ายๆ เหล่านี้ ในแต่ละชนิดของข้อมูลอ้างอิง

• อธิบาย “ความหมาย” ของข้อมูลอ้างอิง ทั้งทางด้านความเข้าใจทางธุรกิจ และทางด้านการใช้งานในระบบ IT
  • ตัวอย่างเช่น “สินค้า” มีความหมายรวมถึงสินค้าที่เป็นของแจกแถมด้วยหรือไม่ สินค้าเก่าหยุดจำหน่ายนานแค่ไหน ถึงจะถูกพิจารณาว่า ไม่ต้องการให้ปรากฎในรายงานการขายอีกต่อไป ในระบบคอมพิวเตอร์ที่ใช้อยู่ มีการบันทึก “สินค้าลวง” (dummy) ไว้บ้างหรือเปล่า? อาจจะเพื่อความสะดวกในการปรับยอดทางบัญชี
• อธิบาย “กระบวนการจัดการ” ข้อมูลอ้างอิง ไม่ว่าจะเป็นการสร้างเพิ่ม การเปลี่ยนแปลง หรือการลบข้อมูลอ้างอิง
  • ตัวอย่างเช่นข้อมูล “ลูกค้า” ใครเป็นคนอนุมัติให้สร้างลูกค้ารายใหม่ขึ้นได้ในระบบ ใครเป็นคนบันทึกลงในฐานข้อมูล ถ้าลูกค้าขอการเปลี่ยนแปลงที่อยู่ในการจัดส่งสินค้า ใครจะเป็นคนแจ้งให้ฝ่ายบันทึกข้อมูลทราบ หรือถ้ามีการเปลี่ยนแปลงพนักงานขายที่ดูแลลูกค้ารายนี้ พนักงานบันทึกข้อมูลจะทราบได้อย่างไร
• ประมาณการปริมาณข้อมูลที่ “สอดคล้องกับความต้องการ” ของระบบ
  • ตัวอย่างเช่น หากต้องการทำรายงานยอดขายรายจังหวัดและรายอำเภอของบริษัทที่มีลูกค้า 20,000 ราย ในบรรดาลูกค้าทั้งสองหมื่นรายนั้น มีจำนวนมากน้อยเท่าไหร่ที่มีข้อมูลจังหวัดและอำเภอบันทึกอยู่ในฐานข้อมูล เป็นไปได้มากทีเดียวที่จะมีลูกค้าเป็นจำนวนมาก ที่มีแต่ข้อมูลจังหวัด แต่ไม่รู้ว่าอยู่ในอำเภออะไร
• ประมาณการปริมาณข้อมูลที่ “ถูกต้องเที่ยงตรง” ตามที่ต้องการ
  • ตัวอย่างเดิม ในบรรดาลูกค้า 20,000 รายที่มีอยู่ในระบบ อาจจะมีแค่ 50% หรือแค่ 10,000 รายเท่านั้นที่มีข้อมูลทั้งอำเภอและจังหวัด แต่กระนั้น ในบรรดา 10,000 รายที่มีข้อมูลจังหวัด อาจจะไม่ได้ถูกต้องเที่ยงตรงอย่างที่ต้องการก็เป็นได้ อาทิเช่น ความแตกต่างระหว่าง กรุงเทพฯ กับ กทม. หรือโคราชกับนครราชสีมา นี่ยังไม่นับโอกาสที่จะพิมพ์ผิดตกเกินอีกมากมาย ข้อมูลอ้างอิงของลูกค้า 20,000 ที่อยู่ในสภาพดีพร้อมใช้งานได้เลยอาจจะเหลืออยู่แค่ไม่ถึง 5,000 รายก็เป็นได้

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

ใน ระหว่างการเตรียมจัดงานประชุมประจำปีภายในของ 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 (ไม่เฉพาะแค่ระบบ แต่รวมไปถึงขั้นตอนกระบวนการในการควบคุมคุณภาพข้อมูลด้วย) น่าจะเป็นทางเลือกหนึ่งที่เพิ่มศักยภาพทางการแข่งขันได้มาก

ห่าง หายไปนาน เดี๋ยวจะคิดว่า series Master Data Management จบไปเสียแล้ว ยังครับ ยังไม่ได้เริ่มเลยด้วยซ้ำ แต่ก่อนจะเริ่มพูดถึง MDM ระดับทั่วทั้งองค์กร ลองมามองถึงปัญหาที่เกิดขึ้น เนื่องจากคุณภาพของข้อมูลอ้างอิงกันก่อน เริ่มกันที่ระบบงานคอมพิวเตอร์เพียงระบบเดียวนี่แหละ เพื่อให้เห็นภาพชัดเจนขึ้น ผมยกตัวอย่างว่า เรากำลังจะออกแบบและพัฒนาระบบลูกค้าสัมพันธ์ของร้านเช่าวีดีโอ (หรือน่าจะเป็น VCD/DVD แล้วสมัยนี้) แห่งหนึ่งในต่างจังหวัด ถ้าจะเรียกให้หรูหน่อยอาจจะเป็น CRM (Customer Relationship Management) ย่อยๆ ก็คงพอได้ ประมาณว่าเจ้าของกิจการรุ่นลูก เพิ่งจบ MBA มาหมาดๆ อยากทำแคมเปญการตลาดกระตุ้นยอดเช่าของลูกค้ารายเดิมๆ ก็อยากได้ระบบไอทีที่เก็บข้อมูลการติดต่อกับลูกค้าแต่ละรายไว้ อาทิเช่น ชื่อที่อยู่หมายเลขโทรศัพท์ รายการหนังที่เคยเช่าไป หรือรายการหนังค้างส่ง เป็นต้น เพื่อจะปรับกิจกรรมทางการตลาดได้

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

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

ผมมองว่าปัญหาเกี่ยวกับคุณภาพของข้อมูลอ้างอิง แบ่งได้เป็นสามส่วน และมีความเกี่ยวโยงกัน ดังนี้

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

• รหัสหรือหมายเลขลูกค้าหนึ่งรายการ แทนอะไรในโลกแห่งความเป็นจริง บุคคลหนึ่งคน หรือหนึ่งครอบครัว
• แล้วถ้าจะมีนิติบุคคลมาสมัครเป็นลูกค้าเพื่อเช่าหนัง จะได้ไหม ?
• จะใช้ข้อมูลใดเป็นดัชนีแยกความแตกต่างของลูกค้าแต่ละราย ? ชื่อ หมายเลขประจำตัวประชาชน หมายเลขโทรศัพท์ เลขที่บ้าน ?
• แล้วถ้าลูกค้าเกิดเปลี่ยนชื่อละ จะถือเป็นลูกค้าอีกรายหนึ่งเลยหรือไม่ ?
• จะจัดแบ่งลูกค้าเป็นกลุ่มหรือเป็นหมวดหมู่อย่างไร แบ่งเพื่ออะไร ใช้เกณฑ์อะไรในการแบ่ง เพศ อายุ การศึกษา รูปแบบการดูหนัง
• รหัส ลูกค้า กำหนดอย่างไร เป็นตัวเลข หรือตัวอักษร (ภาษาไทยหรือภาษาอังกฤษ) มีจำนวนกี่หลัก เป็น intelligent code หรือเป็นแค่ running number ?

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

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

3. ล้มเหลวในการนำมาตรฐาน นิยาม และกฎธุรกิจมาบังคับใช้ในระบบงานคอมพิวเตอร์
ต่อ ให้มีการกำหนดมาตรฐานและนิยามข้อมูล ตลอดจนกฎเกณฑ์ทางธุรกิจไว้แล้ว แต่หากไม่นำข้อกำหนดเหล่านั้นมา “บังคับใช้” ให้ผสานรวมเป็นส่วนหนึ่งในระบบงานคอมพิวเตอร์แล้ว ก็ย่อมเกิดความผิดพลาดเนื่องจาก human error ได้เสมอ ไม่ว่าจะด้วยความตั้งใจหรือไม่ก็ตาม ระบบงานคอมพิวเตอร์ที่ดี จึงควรนำข้อกำหนดที่ได้ระบุไว้ข้างต้น มาใส่ไว้เป็นส่วนหนึ่งของข้อกำหนดในการออกแบบระบบด้วย ไม่ว่าจะเป็นการตรวจสอบความสอดคล้องของข้อมูลด้วย referential integrity หรือ foreign key check การใช้ database trigger และ/หรือ cascade update-delete เพื่อบังคับใช้กฏทางธุรกิจให้เหมาะสม

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

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

ยกตัวอย่างการขาย (Sales) การขายเป็น transaction หรือธุรกรรม ที่เกิดปฎิสัมพันธ์ระหว่าง entity มากกว่าหนึ่งอย่าง คือ สินค้า ผู้ขาย สถานที่ขาย เวลาที่ขาย ในกรณีนี้ สินค้า ผู้ขาย สถานที่ขาย เวลาที่ขาย ต่างก็เป็น master data ทั้งสิ้น  เพราะถูกอ้างอิงโดยข้อมูล sales transaction

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

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

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

การบริหารข้อมูลอ้างอิง (Master Data Management - MDM) เป็นองค์ประกอบหนึ่งที่สำคัญมากสำหรับการจัดการคุณภาพของข้อมูลโดยรวม โดยถือเป็นส่วนประสานงาน ที่เชื่อมโยงองค์ประกอบอื่นของงาน BI เข้าด้วยกัน

โดยนิยาม การบริหารข้อมูลอ้างอิง หมายถึง “กลุ่มของแนวทางปฏิบัติ และวิธีการ ในการทำให้ข้อมูลอ้างอิงของบริษัท มีความถูกต้องเที่ยงตรง สอดคล้องกันทั้งภายในระบบ และระหว่างระบบต่างๆ ในองค์กร”

บทความในชุดนี้จะยกตัวอย่างให้เห็นความสำคัญของ MDM แล้วค่อยอธิบายถึงลำดับขั้นพัฒนาการของการบริหารข้อมูลอ้างอิงในขั้นต่างๆ