Salesforce เป็นหนึ่งในหลายระบบ

🌐 มีให้อ่านอีก 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 ในบท ทำความเข้าใจข้อมูลองค์กร บทที่ 4 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ถัดไป: ประเภทของข้อมูลองค์กร

คำถามที่โมดูลนี้ตอบ: ทำไมสถาปนิกข้อมูลจึงวาดสิ่งที่อยู่รอบ org ก่อนออกแบบ org?

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

นั่นคือการเปลี่ยนมุมมองสำหรับคนทำงาน Salesforce จำนวนมาก ถ้าคุณทำงานมาทั้งอาชีพในฐานะผู้ดูแลระบบหรือนักพัฒนา Salesforce ย่อมเป็นศูนย์กลางของโลกคุณ คุณเปิด Setup สร้างออบเจกต์ สร้าง flow เขียน Apex และผสานระบบอื่นเข้า Salesforce ทุกอย่างดูเหมือนเริ่มจาก org สถาปนิกต้องถอยกล้องออกมา เพราะในองค์กร Salesforce เป็นหนึ่งในหลายระบบ และบ่อยครั้งมันไม่ใช่ระบบที่เป็นเจ้าของข้อมูล

วาดภาพรวมระบบก่อน

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

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

บ่อยครั้ง Salesforce ไม่ใช่ระบบต้นทางหลัก

ลองดูองค์กรที่พบบ่อยมาก: Salesforce บวก ERP ระบบวางแผนทรัพยากรองค์กรอย่าง SAP หรือ Oracle ที่ดูแลการเงิน สินค้า สินค้าคงคลัง การจัดซื้อ และการส่งมอบ ทีนี้ถามคำถามง่ายๆ: ลูกค้าอยู่ที่ไหน?

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

การผสานรวมที่ผมเห็นซ้ำแล้วซ้ำเล่า

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

โฟลว์เหล่านั้นไม่ได้เป็นแค่การผสานรวม มันบอกผมว่าองค์กรเชื่อว่าความจริงอยู่ที่ไหน

ลูกศรทางเดียวทำให้ผมกังวล

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

นั่นคือคำถามที่ผมถามกับลูกศรทุกเส้น: โฟลว์นี้พึ่งพาอะไร? ลูกศรระดับสูงที่คุณเห็นมักต้องการโฟลว์ย้อนกลับที่คุณยังไม่ได้วาด

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

องค์กรไม่ได้เกิดขึ้นในครั้งเดียว

ภาพรวมระบบซับซ้อนส่วนหนึ่งเพราะไม่มีใครสร้างมันทั้งหมดในครั้งเดียว ข้อมูลมาเป็นระลอก ไฟล์ก่อน: เรกคอร์ดแบบความยาวคงที่ แล้วไฟล์แบบมีตัวคั่นอย่าง CSV แล้วฐานข้อมูลเชิงสัมพันธ์สำหรับข้อมูลปฏิบัติการ แล้วคลังข้อมูลเพื่อรวมมันมาวิเคราะห์ แล้วฐานข้อมูล NoSQL สำหรับเอกสาร คู่ key-value และกราฟที่ไม่ลงตัวในตาราง แล้ว data lake สำหรับข้อมูลดิบและกึ่งโครงสร้างจำนวนมหาศาล และ lakehouse ที่รวมสองอย่างเข้าด้วยกัน event stream อย่าง Kafka หรือ event bus ของ Salesforce เคลื่อนย้ายข้อมูลทันทีที่เกิดขึ้น แทนที่จะเป็น batch ทุกคืน และตอนนี้ federation ที่ข้อมูลไม่ต้องถูกคัดลอกไปไว้ที่เดียวก่อนที่แพลตฟอร์มอื่นจะใช้มันได้

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

ระบบต่างกันมีอยู่ด้วยเหตุผลต่างกัน

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

บทที่ 3 ถามว่า ข้อมูลนี้ควรอยู่ที่ไหน? สำหรับ org เดียว ในระดับองค์กร คำถามเดียวกันใหญ่ขึ้น: บางครั้ง Salesforce เป็นเจ้าของข้อมูล บางครั้งเก็บสำเนา บางครั้งแค่การอ้างอิง และบางครั้งไม่ควรมีมันเลย

Core, Off-Core และ Hyperforce

มีอีกขอบเขตหนึ่งที่ต้องเข้าใจ: แม้แต่ “Salesforce” ก็ไม่ใช่รันไทม์เดียวและฐานข้อมูลเดียว ในบทที่ 3 บน core หมายถึงที่ที่ข้อมูลอยู่: บนโต๊ะของคุณ ในออบเจกต์ของ org เอง ในที่นี้คำเดียวกันอธิบายว่าผลิตภัณฑ์หนึ่งรันอยู่ที่ไหน คุณจะได้ยินสถาปนิกใช้ทั้งสองความหมาย

ในอดีตรันไทม์ Core โฮสต์แพลตฟอร์มส่วนใหญ่ วันนี้ Salesforce อธิบายแพลตฟอร์มว่าประกอบด้วยบริการอิสระที่ขับเคลื่อนด้วยเมทาดาทาหลายร้อยบริการ โดย Core ยังคงเป็นระบบต้นทางหลักเพียงระบบเดียวของเมทาดาทาแอปพลิเคชัน (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) ภาษาอังกฤษ) นั่นคือเหตุผลที่คุณจะได้ยินสถาปนิกพูดว่าความสามารถหนึ่งรัน บน core หรือ นอก core

เรื่องนี้สำคัญมานานก่อนที่แพลตฟอร์มจะแยกเป็นบริการ เมื่อผมถามในคลาสว่าทำไม Salesforce ซื้อ SteelBrick มาทำใบเสนอราคาแทนที่จะเป็น Apttus คำตอบที่ผมรอฟังนั้นง่าย: SteelBrick สร้างบน core 100% Flow และ trigger อยู่ใน core ผลิตภัณฑ์ที่สร้างตรงนั้นจึงได้เมทาดาทา การปรับแต่ง และระบบอัตโนมัติของแพลตฟอร์มไปด้วย ผลิตภัณฑ์ใบเสนอราคานั้นได้หลีกทางให้ Revenue Cloud ไปแล้ว แต่บทเรียนยังอยู่ แล้วก็มี near-core (ใกล้ core) และ Data 360 คือตัวอย่างที่ผมใช้ Data 360 ไม่ใช่ core tenant ของมันอยู่นอก core: ข้อมูลและกลไกที่ประมวลผลข้อมูลนั้นรันอยู่ใน lakehouse ของมันเอง เคียงข้างฐานข้อมูลเชิงสัมพันธ์ของ org ไม่ได้อยู่ข้างใน (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) ภาษาอังกฤษ) แต่หน้าจอที่คุณใช้ตั้งค่าและควบคุมมันแสดงอยู่บน core ใน org ดังนั้นวิธีพูดที่แม่นยำที่สุดที่ผมทำได้คือ: จัดการบน core โฮสต์นอก core ไม่มีข้อมูลหรือการประมวลผลใดรันอยู่ใน Core จริงๆ UI บน Core ควบคุม tenant ที่อยู่นอก core และแน่นอน ยังมีทุกอย่างที่อยู่นอก core เพราะมันไม่ใช่ Salesforce เลย

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

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

ภาพรวมระบบมาก่อนกล่อง

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

Click to enlarge

ขั้นที่ 1 จาก 3: org ที่เราออกแบบ เมื่อมองแยกเดี่ยวๆ จากตรงนี้มันดูเหมือนทั้งโลก

Click to enlarge

ขั้นที่ 2 จาก 3: ถอยออกมามอง Salesforce เป็นหนึ่งในหลายระบบ (โมดูล 4 สอนเลย์เอาต์นี้)

Click to enlarge

ขั้นที่ 3 จาก 3: ลูกศรชุดแรก ลูกค้า สินค้า และราคาเข้ามาจาก ERP คำสั่งซื้อออกไป: ลูกศรเหล่านี้บอกว่าองค์กรเชื่อว่าความจริงอยู่ที่ไหน

ภาพรวมระบบเปลี่ยนโมเดลข้อมูล

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

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

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

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

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

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

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)