ธรรมาภิบาลถูกออกแบบไว้ใน org

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 1 จาก 6 ในบท คุณภาพและธรรมาภิบาลข้อมูล บทที่ 5 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ถัดไป: กันข้อมูลไม่ดีออกไป

คำถามที่โมดูลนี้ตอบ: ธรรมาภิบาลข้อมูลหมายถึงอะไรสำหรับสถาปนิก และใครทำอะไร?

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

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

ธรรมาภิบาลไม่มีวันเสร็จ

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

เมื่อ Salesforce อยู่เกือบลำพัง ธรรมาภิบาลหมายถึงการทำความสะอาดข้อมูลในที่เดียว เมื่อมันเป็นหนึ่งโหนดในภาพรวมระบบจากบทที่ 4 มันยากขึ้น และจำเป็นขึ้น ตอนนี้ลูกค้าอยู่ใน Salesforce, ERP คลังข้อมูล ระบบของพันธมิตร และ Data 360 ใครเป็นเจ้าของ? ใครเปลี่ยนได้? สำเนาไหนมีอำนาจชี้ขาด แอตทริบิวต์ใดย้ายได้ เก็บไว้นานเท่าไร และใครรับผิดชอบเมื่อมันผิด? นั่นไม่ใช่คำถามการตั้งค่า มันคือคำถามธรรมาภิบาลที่กลายเป็นการตั้งค่า

เจ้าของเรกคอร์ดไม่ใช่เจ้าของข้อมูล

เริ่มจากคำว่าเจ้าของ เพราะ Salesforce ทำให้มันสับสน เปิดบัญชีหนึ่งแล้วคุณเห็น Owner: สมมติว่าเป็นพนักงานขาย พนักงานขายเป็นเจ้าของข้อมูลลูกค้าไหม? ไม่จำเป็น บน Salesforce เรกคอร์ดบนออบเจกต์ที่มีเจ้าของจะเป็นของผู้ใช้หรือคิว เจ้าของได้สิทธิ์เข้าถึงเต็มที่ และเจ้าของขับเคลื่อนการมอบหมายและการแชร์ผ่านลำดับชั้นบทบาทและกฎการแชร์ (Sharing and Record Access Features (opens in a new tab) ภาษาอังกฤษ) นั่นคือความเป็นเจ้าของเรกคอร์ด: กลไกของแพลตฟอร์ม

เจ้าของข้อมูลเป็นอีกเรื่อง: บุคคลหรือหน่วยงานที่รับผิดชอบข้อมูลในฐานะทรัพย์สินทางธุรกิจ ฝ่ายการเงินอาจเป็นเจ้าของข้อมูลลูกค้าตามกฎหมาย ฝ่ายปฏิบัติการเป็นเจ้าของสถานะการจัดส่ง ฝ่ายบุคคลเป็นเจ้าของข้อมูลพนักงาน Salesforce ถึงกับให้ที่สำหรับบันทึกสิ่งนั้น: ฟิลด์การจัดประเภท Data Owner บนแต่ละฟิลด์ (Data Classification Metadata Fields (opens in a new tab) ภาษาอังกฤษ)

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

เจ้าของ ผู้ดูแลข้อมูล ผู้ปฏิบัติการระบบ

สามบทบาทด้านธรรมาภิบาล สามงานที่ต่างกัน

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

ผู้ดูแลข้อมูลทำให้มันทำงานได้ ผู้ดูแลข้อมูลอยู่ใกล้กับสุขภาพของข้อมูลในแต่ละวัน: เฝ้าดูสัญญาณคุณภาพ ตรวจสอบข้อมูลซ้ำ แก้ข้อยกเว้น ประสานการแก้ไข ดูแลคำนิยาม สังเกตกระบวนการที่สร้างข้อมูลไม่ดีซ้ำๆ ยังมีอีกสองงานที่อยู่กับผู้ดูแลข้อมูล เมื่อสองทีมเห็นไม่ตรงกันว่าฟิลด์หนึ่งหมายถึงอะไร ใครเป็นเจ้าของ หรือใครเห็นได้ ผู้ดูแลข้อมูลนำข้อพิพาทไปหาเจ้าของ และดูแลให้การตัดสินใจถูกนำไปปฏิบัติจนจบ และผู้ดูแลข้อมูลสร้างความรู้ความเข้าใจด้านข้อมูล (data literacy): ช่วยให้คนที่ป้อนและใช้ข้อมูลเข้าใจว่ามันหมายถึงอะไร และทำไมกฎจึงมีอยู่ ผู้ดูแลข้อมูลต้องการมากกว่าชื่อบนแผนผัง พวกเขาต้องมีเวลา การมองเห็น กระบวนการ และอำนาจที่จะทำให้ปัญหาถูกแก้ ไม่อย่างนั้น “ผู้ดูแลข้อมูล” ก็กลายเป็นความรับผิดชอบลำดับที่แปดของใครสักคน ที่ถูกดูไตรมาสละครั้ง

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

โปรแกรมดำเนินไปอย่างไร

โปรแกรมธรรมาภิบาลมักมาในสามรูปทรง แบบรวมศูนย์ (centralized): ทีมเดียวเขียนนโยบายและมาตรฐานสำหรับทุกโดเมน มันสอดคล้องกัน แต่อาจกลายเป็นคอขวด และอยู่ห่างจากคนที่ทำงานจริง แบบกระจาย (federated หรือ decentralized): แต่ละโดเมน เช่น การเงิน การขาย หรือปฏิบัติการ กำกับดูแลข้อมูลของตัวเองภายใต้กฎร่วมไม่กี่ข้อ มันอยู่ใกล้งาน แต่คำนิยามจะค่อยๆ เบี่ยงออกจากกันระหว่างโดเมน แบบผสม (hybrid): ทีมกลางขนาดเล็กเป็นเจ้าของมาตรฐานและคำนิยามร่วม และเจ้าของโดเมนกับผู้ดูแลข้อมูลดูแลข้อมูลของตัวเอง องค์กรส่วนใหญ่ที่ผมเห็นลงเอยที่ไหนสักแห่งในแบบผสม สำหรับสถาปนิก รูปทรงนี้ตอบคำถามเชิงปฏิบัติข้อเดียว: ใครอนุมัตินโยบายก่อนที่ผมจะบังคับใช้ และคำนิยามร่วมอยู่ที่ไหน?

ความรู้ที่ออกสอบ รู้จักสามวิธีในการดำเนินโปรแกรมธรรมาภิบาล แบบรวมศูนย์ แบบกระจาย (federated หรือ decentralized) และแบบผสม และแต่ละแบบหมายถึงอะไรต่อคำถามว่าใครกำหนดนโยบาย และคำนิยามร่วมอยู่ที่ไหน

ทำให้ RACI คุ้มกับที่มันอยู่

RACI (ใครเป็นผู้ลงมือ (Responsible) ผู้รับผิดชอบ (Accountable) ผู้ให้คำปรึกษา (Consulted) และผู้รับทราบ (Informed)) ช่วยได้ แต่ไม่ใช่สเปรดชีตยักษ์ที่ทำขึ้นเพราะธรรมาภิบาล “ต้องมี” ผมอยากให้มันตอบคำถามสถาปัตยกรรม เริ่มจากสามคำถามจากบทที่ 4 (คำถามสี่ข้อเบื้องหลังหมวดหมู่): ข้อมูลถูกสร้างที่ไหน ถูกแก้ไขที่ไหน และถูกอ้างอิงที่ไหน? นั่นมักเป็นคนละระบบ ลองดูสินค้า: ERP สร้างมัน Salesforce อ้างอิงมัน พอร์ทัลแสดงมัน คลังข้อมูลวิเคราะห์มัน ทีนี้ธุรกิจเปลี่ยนความหมายของ “สินค้าที่ใช้งานอยู่” การเปลี่ยนแปลงเริ่มที่ไหน ใครอนุมัติ มันกระจายอย่างไร และสำเนาใดเป็นแบบอ่านอย่างเดียว? ถ้าคุณตอบไม่ได้ คุณยังไม่มีธรรมาภิบาล คุณมีแค่สำเนา RACI ที่ดีเปิดเผยความคลุมเครือนั้นพอดี

ธรรมาภิบาลต้องกลายเป็นกลไก

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

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

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

Click to enlarge

เจ้าของกำหนดนโยบาย สถาปนิกบังคับใช้

อย่าพึ่งพฤติกรรมที่ดี

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

ธรรมาภิบาลข้ามขอบเขตของระบบ

กลับไปที่ภาพรวมระบบ ERP เป็นเจ้าของลูกค้า Salesforce คลังข้อมูล และแพลตฟอร์มข้อมูลลูกค้า (customer data platform) ถือสำเนา พันธมิตรได้บางส่วน นโยบายใช้กับระบบไหน? ทุกระบบ Salesforce อาจบล็อกการเปลี่ยนชื่อตามกฎหมายได้ถูกต้อง ขณะที่การผสานรวมปล่อยให้ระบบปลายน้ำเขียนทับ Salesforce อาจลบข้อมูลส่วนบุคคลที่คลังข้อมูลยังถืออยู่ ฟิลด์ที่จัดประเภทเป็นอ่อนไหวใน Salesforce อาจไปลงในฟิลด์ข้อความที่ไม่ได้จัดประเภทที่อื่น ธรรมาภิบาลหยุดที่ขอบของ org ไม่ได้ เพราะข้อมูลไม่ได้หยุด นั่นคือเหตุผลที่บทที่ 4 มาก่อน: ภาพรวมระบบบอกคุณว่าธรรมาภิบาลต้องเอื้อมไปไกลแค่ไหน

กำกับดูแลให้พอ ไม่ใช่ทุกอย่าง

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

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

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

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

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

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

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

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)