สี่วิธีในการจัดการข้อมูลหลัก

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 2 จาก 6 ในบท ข้อมูลหลักและตัวตน บทที่ 6 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: แหล่งความจริงเดียวต่อหนึ่งแอตทริบิวต์ · ถัดไป: การจับคู่ การผสาน และการคงค่า

คำถามที่โมดูลนี้ตอบ: องค์กรจัดการข้อมูลหลักอย่างไร และรูปแบบไหนเหมาะ?

โมดูลที่ 1 บอกว่าอำนาจชี้ขาดถูกกำหนดทีละแอตทริบิวต์ ทีนี้: เราจะทำอย่างไรเมื่อแอตทริบิวต์เหล่านั้นอยู่ในหลายระบบพร้อมกัน? ข้อมูลลูกค้าใน Salesforce, ERP ระบบเรียกเก็บเงิน ระบบสนับสนุน อาจมี Data 360 อาจมีคลังข้อมูล แต่ละที่มีเวอร์ชันของตัวเอง นั่นคือปัญหาที่ การจัดการข้อมูลหลัก (MDM) พยายามแก้ และ MDM ไม่ใช่สถาปัตยกรรมเดียว คุณจะได้ยินสี่รูปแบบ: registry การรวบรวม (consolidation) การอยู่ร่วมกัน (coexistence) และแบบรวมศูนย์ (centralized) มันไม่ใช่การตั้งค่าของผลิตภัณฑ์ มันคือสี่คำตอบของคำถามเดียว: ชั้นการจัดการข้อมูลหลักมีอำนาจชี้ขาดแค่ไหน?

เริ่มจากปัญหา ไม่ใช่ผลิตภัณฑ์

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

Registry: บอกผมว่าใครคือใคร

รูปแบบที่เบาที่สุด Registry (ทะเบียนกลาง) ไม่ได้แทนที่แหล่งข้อมูล ERP เก็บลูกค้าของตัวเอง Salesforce เก็บบัญชีของตัวเอง ระบบเรียกเก็บเงินเก็บลูกค้าของตัวเอง และ registry หาว่าเรกคอร์ดเหล่านี้แทนเอนทิตีเดียวกัน: บัญชี Salesforce 001… ลูกค้า ERP SAP-43821 และลูกค้าระบบเรียกเก็บเงิน BILL-9127 เป็นของลูกค้ารายเดียว แหล่งข้อมูลอยู่ที่เดิมและไม่ถูกเขียนทับ ตอนนี้ “แสดงทุกอย่างที่เรารู้เกี่ยวกับลูกค้ารายนี้” ก็มีคำตอบ

แต่สังเกตสิ่งที่ registry ไม่ได้ตอบ Salesforce บอก 123 Main Street, ERP บอก 125 ระบบเรียกเก็บเงินบอก “123 Main St., Suite 200” registry รู้ว่ามันเป็นของคนเดียวกัน แต่ไม่ได้ตัดสินว่าอันไหนควรเปลี่ยน การเชื่อมโยงไม่ใช่การจัดการข้อมูลหลัก

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

Click to enlarge

registry ตอบว่า: เรกคอร์ดไหนเป็นของสิ่งเดียวกัน?

การรวบรวม: นำข้อมูลมารวมกัน

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

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

Click to enlarge

การรวบรวมนำข้อมูลมารวมกันโดยไม่เอาความเป็นเจ้าของไปจากต้นทาง

การอยู่ร่วมกัน: ตัดสินใจ แล้วส่งกลับไป

ในการอยู่ร่วมกัน (coexistence) ชั้นการจัดการข้อมูลหลักได้อำนาจชี้ขาดจริง ข้อมูลยังอยู่ในหลายระบบเชิงปฏิบัติการ แต่กระบวนการ MDM ตัดสินค่าหลักแล้วเผยแพร่กลับไป Salesforce, ERP และระบบเรียกเก็บเงินต่างมีชื่อตามกฎหมายไม่ตรงกัน กระบวนการ MDM กำหนดชื่อที่มีธรรมาภิบาลแล้วกระจายไปทั้งสามระบบ ระบบต่างๆ อยู่ร่วมกัน แต่มาบรรจบที่ค่าหลัก

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

Click to enlarge

การอยู่ร่วมกันไม่ได้แค่เชื่อมโยงเรกคอร์ด มันตัดสินค่าหลักและส่งกลับไป

แบบรวมศูนย์: ตัวหลักสร้างความจริง

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

Click to enlarge

MDM แบบรวมศูนย์ย้ายการสร้างและอำนาจชี้ขาดเข้าไปไว้ในตัวหลัก

สี่แบบเทียบกัน

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

ยิ่งลงไปในตาราง ชั้นการจัดการข้อมูลหลักยิ่งได้อำนาจชี้ขาดมากขึ้น และองค์กรมักต้องเปลี่ยนมากขึ้น

ความรู้ที่ออกสอบ รู้จักรูปแบบการ implement MDM ทั้งสี่: registry (เชื่อมโยงตัวตน ต้นทางเก็บข้อมูลของตนไว้) การรวบรวม (consolidation) (นำข้อมูลมารวมกัน มักเพื่อการวิเคราะห์) การอยู่ร่วมกัน (coexistence) (ตัดสินค่าหลักและเผยแพร่กลับไปยังต้นทาง) และแบบรวมศูนย์ (centralized) (ตัวหลักสร้างข้อมูล ต้นทางเป็นผู้ใช้)

ดังนั้นไม่มี “แบบรวมศูนย์คือวุฒิภาวะสูงสุด ทุกคนจึงควรไปให้ถึง” เลือกรูปแบบที่เบาที่สุดที่แก้ปัญหาได้ ต้องรู้ว่าเรกคอร์ดเป็นของเดียวกัน? คิดถึง registry มุมมองรวมสำหรับการวิเคราะห์? การรวบรวม ค่าที่มีธรรมาภิบาลซิงก์กลับไปยังหลายระบบเชิงปฏิบัติการ? การอยู่ร่วมกัน กระบวนการเดียวที่สร้างและควบคุมข้อมูลหลักให้ทุกคน? แบบรวมศูนย์

Data 360 อยู่ตรงไหน?

Data 360 สร้างโปรไฟล์รวมข้ามหลายแหล่ง ซึ่งฟังดูคล้าย MDM มาก และมันก็แก้ปัญหาส่วนหนึ่งได้ identity resolution ของมันจับคู่โปรไฟล์ต้นทางเป็นตัวตนรวม และเก็บการเชื่อมโยงกลับไปยังเรกคอร์ดต้นทางไว้ (Data 360 Architecture (opens in a new tab) ภาษาอังกฤษ) นั่นทำให้มันใกล้กับ registry มากที่สุด มันยังแสดงค่าที่กระทบยอดแล้วบนโปรไฟล์รวมได้ แต่นั่นไม่ได้ทำให้มันเป็นระบบ golden record แบบรวมศูนย์ที่เขียนแหล่งข้อมูลใหม่ มุมมองรวมไม่ได้เป็นเรกคอร์ดองค์กรที่จัดการแล้วโดยอัตโนมัติ โมดูลที่ 4 พูดถึงความต่างนั้นทั้งโมดูล

โมเดลร่วมไม่ใช่ความจริงร่วม

คุณจะได้ยินคำว่า canonical data model (โมเดลข้อมูลมาตรฐานกลาง) ด้วย Account ของ Salesforce, business partner ของ ERP และ customer ของระบบเรียกเก็บเงิน ทั้งหมดจับคู่กับแนวคิดระดับองค์กรเดียวที่ตกลงกัน คือ Customer พร้อมตัวระบุและแอตทริบิวต์ที่ตกลงกัน เพื่อที่ทุกการผสานรวมจะไม่ต้องเข้าใจรูปร่างของทุกระบบอื่น โมเดลข้อมูลของ Data 360 เป็นตัวอย่างของการปรับแหล่งข้อมูลให้สอดคล้องกันเป็นแนวคิดร่วม แต่โมเดลมาตรฐานกลางตอบว่า เราจะแสดงสิ่งนี้อย่างสม่ำเสมอได้อย่างไร? MDM ตอบว่า เราจะระบุ กำกับดูแล และจัดการข้อมูลหลักของมันข้ามระบบได้อย่างไร? จับคู่ทั้งสามระบบเป็นรูปร่าง Customer เดียวได้สมบูรณ์แบบ แล้ว Salesforce ก็ยังบอก 123 Main Street ขณะที่ ERP บอก 125 คุณแก้โครงสร้างได้ ไม่ใช่อำนาจชี้ขาด การปรับให้สอดคล้องกันกับการจัดการข้อมูลหลักใช้แทนกันไม่ได้

ธุรกิจเดียว หลายรูปแบบ

ดังนั้น “Steve Trucking ต้องการ MDM” ไม่ใช่ความต้องการ สำหรับอะไร? พันธมิตรค้าปลีก ศูนย์กระจายสินค้า ทีมจัดส่ง รถบรรทุก ผู้รับ เป็นโดเมนต่างกันที่มีผู้มีอำนาจชี้ขาดต่างกัน: พันธมิตรค้าปลีกถูกกำกับดูแลใน Salesforce และ ERP ฝ่ายการเงิน ตัวตนของรถบรรทุกมาจาก FleetLink ผู้รับแต่ละคนถูกส่งมาโดยพันธมิตรสำหรับการจัดส่งแต่ละครั้ง โดเมนต่างกันใช้รูปแบบต่างกันได้ และภายในโดเมนเดียว แอตทริบิวต์ก็มีผู้มีอำนาจชี้ขาดต่างกันได้ ดังนั้นอย่าวาดกล่องที่ติดป้าย MDM ไว้กลางไดอะแกรมแล้วบอกว่าแก้แล้ว ถามว่ากล่องนั้นทำอะไร

รูปแบบยังเปลี่ยนการผสานรวมด้วย registry ต้องการการเชื่อมโยงตัวตน การรวบรวมต้องการโฟลว์ขาเข้าที่เชื่อถือได้ การอยู่ร่วมกันต้องการข้อมูลทั้งสองทิศทาง แบบรวมศูนย์ต้องการการกระจายจากตัวหลักพร้อมการควบคุมที่หยุดระบบอื่นไม่ให้สร้างความจริงคู่แข่ง เมื่ออำนาจชี้ขาดเพิ่มขึ้น การประสานงานก็เพิ่มขึ้น และการจัดการความล้มเหลวก็เช่นกัน: ถ้า MDM เปลี่ยนชื่อตามกฎหมายแล้ว ERP ปฏิเสธล่ะ? นั่นคือเหตุผลที่การอยู่ร่วมกันและแบบรวมศูนย์ไม่ใช่ “registry ที่มีฟีเจอร์มากขึ้น” มันมีความรับผิดชอบเชิงปฏิบัติการที่ต่างกัน

MDM คือการตัดสินใจทางธุรกิจ

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

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

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

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

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

ศึกษาเพิ่มเติม

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)