กันข้อมูลไม่ดีออกไป

🌐 มีให้อ่านอีก 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 ในบท คุณภาพและธรรมาภิบาลข้อมูล บทที่ 5 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ธรรมาภิบาลถูกออกแบบไว้ใน org · ถัดไป: รู้จักข้อมูลของคุณ

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

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

“ดีพอ” คือคำนิยามทางธุรกิจ

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

ป้องกันความผิดพลาดที่มีราคาแพง

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

เปิดหรือล็อก?

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

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

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

ทางสายกลาง: ประเภทเรกคอร์ดชั่วคราว

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

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

ประเภทเรกคอร์ดสำหรับแต่ละโฟลว์

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

Click to enlarge

ประเภทเรกคอร์ดสำหรับแต่ละโฟลว์: บัญชี Sales ไหลออก บัญชี ERP ไหลเข้า

มันไม่ได้ทำให้กรณียากหายไป พนักงานขายแปลงลูกค้าเป้าหมายของ Steve’s Plumbing แต่ Steve’s Plumbing มีอยู่แล้วในฐานะบัญชี ERP และการตรวจข้อมูลซ้ำก็จับไม่ได้ด้วยเหตุผลบางอย่าง ตอนนี้คุณกำลังผสานเรกคอร์ด ย้ายเรกคอร์ดลูกไปหาพ่อแม่ใหม่ และตัดสินว่าเรกคอร์ดไหนอยู่รอด (บทที่ 6 โมดูลที่ 3)

และอย่าไปติดอยู่กับตัวประเภทเรกคอร์ดเอง ปกติผมหลีกเลี่ยงประเภทเรกคอร์ด เว้นแต่จะมีเหตุผลที่หนักแน่น ผมใช้มันที่นี่เพราะก่อนมี Dynamic Forms ประเภทเรกคอร์ดเป็นตัวเลือก page layout และ layout หนึ่งแสดงฟิลด์ ERP เป็นแบบอ่านอย่างเดียว เมื่อมี Dynamic Forms กฎการมองเห็นสามารถแสดงและซ่อนฟิลด์ตามค่าของฟิลด์ได้ ฟิลด์หนึ่งเป็นแบบอ่านอย่างเดียวบนหน้าหนึ่งได้ และ Salesforce เองก็บอกว่า Dynamic Forms ลดจำนวน page layout และประเภทเรกคอร์ดที่คุณต้องใช้ (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab) ภาษาอังกฤษ) แต่อ่านอย่างเดียวบนหน้าหนึ่งก็คืออ่านอย่างเดียวบนหน้านั้น: API การโหลดข้อมูล หรือการผสานรวม ยังเขียนฟิลด์นั้นได้ การบังคับใช้จริงคือความปลอดภัยระดับฟิลด์หรือกฎการตรวจสอบความถูกต้อง การตรวจสอบใน UI ไม่ใช่การตรวจสอบข้อมูล (บทที่ 3 โมดูลที่ 9) ประเภทเรกคอร์ดยังคุ้มกับที่ของมันเมื่อบัญชีสองแบบต้องการค่า picklist หรือกระบวนการทางธุรกิจที่ต่างกัน สิ่งที่สำคัญจริงๆ คือต้องมีฟิลด์ใดฟิลด์หนึ่งบอกชัดเจนว่าเรกคอร์ดมาจากไหน: ตัวคีย์ของ ERP เอง แฟล็กข้อมูลหลัก หรือ picklist แหล่งที่มา แล้วใช้ฟิลด์นั้นกำหนดว่าแก้ไขได้หรือไม่

Click to enlarge

จากชั่วคราวสู่มีธรรมาภิบาล: ฝ่ายขายเริ่มขายได้ทันที มีแต่กระบวนการที่มีอำนาจชี้ขาดเท่านั้นที่ทำให้เรกคอร์ดมีธรรมาภิบาล

ปกป้องเรกคอร์ดที่มีธรรมาภิบาล

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

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

สิ่งที่ยากที่สุดคือโฟลว์สองทาง (bi-directional) สมมติพนักงานขายต้องการให้เปลี่ยนชื่อตามกฎหมายใน ERP จาก Steve’s Plumbing เป็น Steve’s Plumbing LLC ในห้านาทีเดียวกันนั้น ใครบางคนใน ERP เปลี่ยนมันเป็น Steve’s Plumbing L.L.C. การเปลี่ยนของใครชนะ? นี่คือวิธีคิด: ถ้าฟิลด์หนึ่งมี ERP เป็นตัวหลัก คุณไม่ได้กำลังเปลี่ยนฟิลด์ คุณกำลังขอเปลี่ยนมัน ตัดสินว่าจะเกิดอะไรขึ้นเมื่อคำขอชนกัน: ERP ชนะ คำขอถูกปฏิเสธถ้าค่าเปลี่ยนไปในระหว่างนั้น หรือรอให้คนเป็นผู้แก้ และตัดสินว่าฟิลด์ที่เกี่ยวข้องกันจะเดินทางไปด้วยกันเป็นการเปลี่ยนแปลงเดียว หรือทีละฟิลด์ บทที่ 6 พาเรื่องการชนกันไปไกลกว่านี้ (ลูปและการชนกัน)

หยุดข้อมูลซ้ำที่ประตู

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

ทำให้สิ่งที่เครื่องอ่านเป็นมาตรฐาน

ข้อความอิสระดีมากสำหรับคน และแย่มากเมื่อระบบต้องตีความ ใส่ Arizona, AZ, Ariz., Phoenix area และ Southwest ในฟิลด์ที่ขับเคลื่อนการวางเส้นทาง แล้วคุณก็มีปัญหาคุณภาพ ถ้าค่าหนึ่งขับเคลื่อนระบบอัตโนมัติ การผสานรวม การรายงาน ความปลอดภัย การมอบหมาย หรือการกระทำของเอเจนต์ ให้คิดหนักว่ามันต้องเป็นมาตรฐานแค่ไหน ไม่ใช่ทุกฟิลด์ข้อความจะกลายเป็น picklist แต่ให้แยกข้อมูลที่คนอ่านออกจากข้อมูลที่เครื่องใช้ตัดสินใจ แบบหลังสมควรได้รับการควบคุมที่แข็งแรงกว่า

อย่าให้ฟิลด์ที่จำเป็นสร้างข้อมูลปลอม

เราตัดสินว่าฟิลด์หนึ่งสำคัญและทำให้มันจำเป็น ผู้ใช้ไม่รู้คำตอบ ระบบไม่ยอมให้ไปต่อ เขาจึงพิมพ์ N/A, Unknown, 999999 หรือ test@test.com ฟิลด์ครบ ข้อมูลเป็นขยะ ก่อนบังคับอะไร ให้ถามว่าผู้ใช้รู้มันจริงๆ ไหม ณ จุดนั้น ถ้าไม่ ก็บังคับทีหลังในกระบวนการ ให้ระบบอื่นเป็นผู้ส่งค่ามา ใช้สถานะชั่วคราว หรือให้ตัวเลือก Unknown อย่างชัดเจนเมื่อไม่รู้เป็นคำตอบที่ถูกต้อง กฎการตรวจสอบความถูกต้องบังคับใช้นโยบายได้ แต่ทำให้ใครรู้สิ่งที่เขาไม่รู้ไม่ได้

ทุกขอบเขตข้อมูลต้องมีการตัดสินใจเรื่องคุณภาพ

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

Click to enlarge

ทุกขอบเขตข้อมูลต้องมีการตัดสินใจเรื่องคุณภาพ

ข้อมูลในอดีตต่างออกไป

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

วัดสิ่งที่จะมีคนลงมือทำ

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

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

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

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

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

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

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) และ Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)