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

โมดูลที่ 5 จาก 6 ในบท ทำความเข้าใจข้อมูลองค์กร บทที่ 4 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: วาดภาพรวมระบบ · ถัดไป: ภาพรวมระบบของ Steve Trucking

คำถามที่โมดูลนี้ตอบ: org เดียวหรือหลาย org และรันที่ไหน?

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

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

เริ่มจาก org เดียว

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

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

หลาย org มีต้นทุน

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

กลับไปที่ภาพรวมระบบจากโมดูลที่ 4 กล่อง Salesforce หนึ่งกล่องกลายเป็นสาม และทุกลูกศรต้องวาดใหม่ หลาย org ไม่ใช่สิ่งผิด แต่มันไม่เคยฟรี

มองหาขอบเขตที่แท้จริง

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

ภูมิศาสตร์ไม่ได้เป็นกลยุทธ์ org โดยอัตโนมัติ

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

การโฮสต์เป็นส่วนหนึ่งของภาพ

ตรงนี้แพลตฟอร์มสมัยใหม่ทำให้ภาพรวมระบบน่าสนใจขึ้น Hyperforce รัน Salesforce บนโครงสร้างพื้นฐานคลาวด์สาธารณะในภูมิภาคต่างๆ ทั่วโลก ทำให้ลูกค้ามีทางเลือกและการควบคุมมากขึ้นว่าข้อมูลของตนอยู่ที่ไหน (Salesforce Hyperforce: General Information and FAQ (opens in a new tab) ภาษาอังกฤษ) ดังนั้นเมื่อผมติดป้ายกล่องว่า “Salesforce, ยุโรป” ตำแหน่งนั้นอาจสำคัญ

แต่ต้องแม่นยำ การเลือกว่า org อยู่ที่ไหนไม่ใช่คำมั่นว่าทุกไบต์ของทุกบริการจะอยู่ที่นั่น Salesforce บอกลูกค้าให้ตรวจสอบเอกสารด้านความไว้วางใจและการปฏิบัติตามกฎสำหรับ Hyperforce รวมถึงผู้ประมวลผลย่อยเพิ่มเติมสำหรับบริการที่ซื้อ (แหล่งเดียวกัน) ดังนั้นอย่าพูดว่า “เราอยู่บน Hyperforce ในประเทศ X ทุกอย่างจึงอยู่ในประเทศ X” รู้ว่าคุณใช้บริการใดจริงๆ และกำลังตอบความต้องการข้อใด และสังเกตสิ่งที่คุณเลือก: ภูมิภาค ไม่ใช่คลาวด์ที่อยู่ข้างใต้ Hyperforce รันบน AWS และบน Google Cloud ตั้งแต่ปลายปี 2026 และ Salesforce เป็นผู้ตัดสินว่า org หนึ่งอยู่บนผู้ให้บริการรายใด ลูกค้าที่มีเหตุผลด้านกฎระเบียบที่มีเอกสารยืนยันว่าต้องหลีกเลี่ยงรายใดรายหนึ่ง ให้คุยกับทีมดูแลลูกค้าของตน (แหล่งเดียวกัน)

อย่าเล่นเป็นทนาย

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

เมื่อยุโรปมี org ของตัวเอง

นี่คือขอบเขตที่ผมเห็นในสถานการณ์จริง บริษัทหนึ่งมีธุรกิจขนาดใหญ่ทั้งในสหรัฐฯ และในยุโรป: ฐานลูกค้าใหญ่สองฐาน งานขายและบริการสองชุด และโปรแกรมความเป็นส่วนตัวของยุโรปที่สร้างขึ้นรอบ GDPR GDPR ไม่ได้บอกว่า “คุณต้องมี org ของ Salesforce แยก” มันวางกฎสำหรับข้อมูลส่วนบุคคล รวมถึงเมื่อใดที่โอนข้อมูลออกนอก EU ได้ (GDPR, Chapter V (opens in a new tab) ภาษาอังกฤษ) แต่บริษัทนี้ ร่วมกับทีมความเป็นส่วนตัวและทีมกฎหมาย ตัดสินใจว่าข้อมูลส่วนบุคคลของลูกค้าในยุโรปควรอยู่ใน org ที่โฮสต์ในยุโรป ดำเนินการโดยทีมยุโรป ภายใต้ธรรมาภิบาลของยุโรป นั่นคือความต้องการจริง และมันเป็นของพวกเขา ไม่ใช่ของผม

ตอนนี้ “org ใหญ่ระดับโลกเพียงหนึ่งเดียว” ไม่ใช่ความชอบอีกต่อไป มีขอบเขตบนภาพรวมระบบ คือ Salesforce AMER และ Salesforce EMEA และผมต้องวาดมัน และ org ที่สองไม่เคยเป็นแค่กล่องเพิ่มอีกหนึ่งกล่อง

Click to enlarge

สอง org คือ AMER และ EMEA สีอำพันคือสิ่งที่ org ที่สองเพิ่มเข้ามา: ไม่ใช่กล่องเพิ่มหนึ่งกล่อง แต่เป็นลูกศรทุกเส้นอีกรอบ

เดินตามลูกศรอีกครั้ง

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

สามจุดแสดงต้นทุนได้เร็วที่สุด:

การรายงาน CEO ต้องการ pipeline ระดับโลก ใน org เดียว นั่นคือรายงาน Salesforce ในสาม org มันคือปัญหาการรายงานระดับองค์กร: ทำสำเนา ส่งไปคลังข้อมูล หรือ federate? ต้องใหม่แค่ไหน และ org ต่างๆ นิยาม “pipeline” เหมือนกันหรือเปล่า? การวิเคราะห์อยู่ที่ไหนขึ้นกับว่าข้อมูลอยู่ที่ไหน และถ้าคุณแยกข้อมูลเชิงปฏิบัติการโดยตั้งใจ คุณต้องออกแบบว่าข้อมูลเชิงลึกจะกลับมารวมกันอย่างไร

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

การผสานรวม org เดียว: Salesforce ชั้นการผสานรวม ERP สาม org: การเชื่อมต่อสามเส้นเข้าชั้นการผสานรวม บางทีหนึ่งในนั้นมีโฮสต์และการเชื่อมต่อของตัวเอง บางโฟลว์ใช้ร่วมกัน บางโฟลว์เป็นระดับภูมิภาค ข้อมูลบางอย่างข้ามได้และบางอย่างไม่ได้ แม้แต่เครือข่ายก็อาจเปลี่ยน: ถ้าองค์กรต้องการการเชื่อมต่อส่วนตัวเฉพาะเข้า Hyperforce (บน AWS Salesforce แนะนำ AWS Direct Connect อ้างอิง FAQ ของ Hyperforce เดียวกัน) ทุก org และโฮสต์บนภาพคืออีกการเชื่อมต่อที่ต้องวางแผน ที่ที่ org รันเปลี่ยนวิธีที่ส่วนที่เหลือขององค์กรเข้าถึงมันได้

org เดียวหรือหลาย org คือการตัดสินใจที่คุณทำตอนนี้ ตั้งแต่ต้น บนภาพรวมระบบ ส่วน org เหล่านั้นจะแชร์ข้อมูลกันอย่างไร (Salesforce Connect ข้าม org การผสานรวมระหว่างกัน Data 360) เป็นเรื่องกลไก และบทที่ 14 org เดียวหรือหลาย org? (coming soon) ครอบคลุมเรื่องนั้น

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

อย่าแยกเพียงเพื่อให้กล่องเล็กลง

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

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

ทำให้การตัดสินใจมองเห็นได้

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

Steve Trucking ใช้ org เดียว ในสหรัฐฯ และไม่มีอะไรในบรีฟเรียกร้องให้มีอีก org แต่จำโมดูลนี้ไว้สำหรับ capstone: การควบรวมกิจการที่มาพร้อม org ของตัวเองคือขอบเขตแบบที่ทดสอบคำถามเหล่านี้พอดี

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

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

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

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

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

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), Chapter V (การโอนข้อมูลส่วนบุคคลไปยังประเทศที่สาม) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)