ลำดับชั้นและข้อมูลสองทาง

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

โมดูลที่ 5 จาก 6 ในบท ข้อมูลหลักและตัวตน บทที่ 6 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: แผนที่ไม่ใช่การตัดสินใจ · ถัดไป: จุดตรวจสอบที่ 1: Steve Trucking

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

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

ข้อมูลสองทางไม่ได้แปลว่ามีเจ้าของหลักสองราย

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

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

Click to enlarge

การผสานรวมแบบสองทิศทางไม่ได้สร้างอำนาจชี้ขาดแบบสองทิศทาง

เมื่อตัวหลักบอกว่าไม่

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

ลูปและการชนกัน

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

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

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

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

ลำดับชั้นก็เป็นข้อมูลหลัก

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

บน Salesforce ลำดับชั้นบัญชีสร้างด้วยฟิลด์ Parent Account มุมมองลำดับชั้นใน Lightning แสดงได้สูงสุด 2,000 บัญชี และเฉพาะบัญชีที่ผู้ใช้มีสิทธิ์เห็น บัญชีบุคคลไม่รองรับในลำดับชั้น และ Account Site แยกสถานที่ต่างๆ ของบริษัท (Considerations for Using Account Hierarchy (opens in a new tab) ภาษาอังกฤษ) แต่ฟิลด์ Parent Account ไม่ได้ตอบคำถามทางสถาปัตยกรรม: ใครเป็นเจ้าของลำดับชั้น?

ความรู้ที่ออกสอบ รู้พื้นฐานของลำดับชั้นบัญชี (account hierarchy): สร้างด้วย Parent Account มุมมองใน Lightning แสดงได้สูงสุด 2,000 บัญชี เฉพาะบัญชีที่ผู้ใช้มองเห็นได้ ไม่รองรับบัญชีบุคคล และ Account Site ใช้แยกสถานที่ต่างๆ ของบริษัท

ลำดับชั้นเดียว หลายเจ้าของหลัก

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

Click to enlarge

อำนาจชี้ขาดของลำดับชั้นกำหนดได้ทีละกิ่ง

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

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

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

ลูกค้ารายเดียว ERP สองระบบ

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

ลองใช้ Steve’s Plumbing เป็นลูกค้า บริษัททำธุรกิจในอเมริกาเหนือ ERP อเมริกาเหนือจึงมีเรกคอร์ดลูกค้าของบริษัทนี้ แล้วบริษัทก็เปิดสำนักงานในมิวนิก และ ERP ยุโรปก็สร้างเรกคอร์ดลูกค้าของตัวเอง พร้อมหมายเลขลูกค้าของตัวเอง บริษัทเดียวกัน สองเรกคอร์ด สอง ID ผมจะแสดงสิ่งนั้นใน org ของ Salesforce หนึ่ง org อย่างไร? ผมเคยเห็นสามวิธี

ลำดับชั้นบัญชี Steve’s Plumbing เป็นแม่ โดยมี Steve’s Plumbing North America และ Steve’s Plumbing Europe เป็นบัญชีลูก แต่ละลูกแทนเรกคอร์ดของ ERP หนึ่งระบบ ข้อติดขัดคือ: บัญชีลูกไม่ใช่ Steve’s Plumbing จริงๆ อีกต่อไป มันคือ Steve’s Plumbing ที่ทำธุรกิจในภูมิภาคหนึ่ง และอย่างที่เราเพิ่งเห็น ลำดับชั้นมีความหมายติดมาด้วย

บัญชีระดับเดียวกัน (peer accounts) สองบัญชีวางเคียงกัน แต่ละบัญชีมีฟิลด์ที่บอกว่ามันเป็นของ ERP ไหน: รหัสบริษัท ภูมิภาค ไม่มีอะไรถูกซ่อน ต้นทุนไปโผล่ในการรายงาน: ถ้าจะดู Steve’s Plumbing ทั่วโลก คุณต้องมีบางอย่างที่บอกว่าสองบัญชีนี้คือบริษัทเดียวกัน

บัญชีเดียว พร้อมลูกหนึ่งตัวต่อ ERP หนึ่งระบบ Steve’s Plumbing หนึ่งเดียว และออบเจกต์ลูกที่มีหนึ่งเรกคอร์ดต่อ ERP แต่ละระบบ เก็บ ID ลูกค้าของ ERP นั้น สอง ERP หรือสิบก็ได้ พนักงานขายเห็นลูกค้ารายเดียวและสั่งซื้อครั้งเดียว เบื้องหลัง Flow ตัดสินว่าแต่ละรายการไปที่ ERP ไหน: งานไฟฟ้าไป ERP ไฟฟ้า งานประปาไป ERP ประปา แต่ตอนนี้คุณต้องตัดสินว่า ERP ไหนเป็นหลักสำหรับค่าที่ใช้ร่วมกัน เช่น ชื่อและที่อยู่ และจะเกิดอะไรขึ้นเมื่อลูกค้ามีอยู่ใน ERP หนึ่งแต่ไม่มีในอีกระบบ

Click to enlarge

ลูกค้ารายเดียว ERP สองระบบ: สามวิธีในการแสดงใน Salesforce

ถามว่าพวกเขาซิงก์ ERP อย่างไร

แล้วเลือกแบบไหน? ข้อแรก: พนักงานขายควรเห็นโครงสร้าง ERP มากแค่ไหน? ถ้าพวกเขารู้มาตลอดว่าอเมริกาเหนือและยุโรปเป็นธุรกิจแยกกัน เพราะพวกเขาล็อกอินเข้า ERP ระบบใดระบบหนึ่ง ก็อย่าซ่อนมันจากพวกเขา นำโครงสร้างนั้นเข้ามาใน Salesforce เป็นบัญชีระดับเดียวกัน ถ้าธุรกิจต้องการให้ฝ่ายขายเห็น Steve’s Plumbing หนึ่งเดียว คุณกำลังมองที่บัญชีเดียวที่มีลูกหนึ่งตัวต่อ ERP

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

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

MDM ตรงกลาง

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

Click to enlarge

MDM ตรงกลาง: Salesforce ชี้ไปที่เดียว

Steve Trucking: ลำดับชั้นของใคร?

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

ทำให้ขอบเขตมองเห็นได้

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

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

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

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

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

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

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

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)