ประเภทของข้อมูลองค์กร

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

คำถามที่โมดูลนี้ตอบ: องค์กรมีข้อมูลประเภทใดบ้าง และทำไมแต่ละประเภทจึงควรอยู่คนละที่?

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

เริ่มจากประเภท ไม่ใช่ออบเจกต์

ในฐานะคน Salesforce เราแปลความต้องการเป็นโครงสร้างแทบจะทันที: ลูกค้าคือบัญชี รูปถ่ายคือ File สถานะคือ picklist นั่นมีประโยชน์ในที่สุด แต่ในระดับองค์กร ผมอยากรู้ก่อนว่ากำลังเจอข้อมูลประเภทไหน มีหลายวิธีในการจัดประเภท (DAMA body of knowledge คือเอกสารอ้างอิงมาตรฐาน) และผมพบว่าหกประเภทมีประโยชน์: ข้อมูลหลัก ข้อมูลอ้างอิง ข้อมูลธุรกรรม เมทาดาทา ข้อมูลเชิงวิเคราะห์ และข้อมูลไม่มีโครงสร้าง หมวดหมู่ไม่ใช่สถาปัตยกรรม มันเป็นวิธีถามคำถามที่ดีกว่า

ข้อมูลหลัก: สิ่งที่ธุรกิจรู้จัก

ข้อมูลหลักอธิบายสิ่งที่คงทนที่ธุรกิจดำเนินไปรอบๆ: ลูกค้า สินค้า ราคา พนักงาน ซัพพลายเออร์ สถานที่ สินทรัพย์ ใน org ฝ่ายขายของ Salesforce นั่นคือบัญชีและผู้ติดต่อ สินค้า และสมุดราคา (price book) ของคุณ ที่ Steve Trucking พันธมิตรค้าปลีก (Retail Partner) คือข้อมูลหลัก Keystone ไม่ใช่เหตุการณ์ มันคือองค์กรที่ Steve Trucking มีความสัมพันธ์ต่อเนื่องด้วย ศูนย์กระจายสินค้าเก้าแห่งก็เป็นข้อมูลหลักเช่นกัน

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

ข้อมูลอ้างอิง: คำศัพท์ที่ธุรกิจใช้ร่วมกัน

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

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

ข้อมูลธุรกรรม: สิ่งที่เกิดขึ้น

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

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

เมทาดาทา: ข้อมูลเกี่ยวกับข้อมูล

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

ข้อมูลเชิงวิเคราะห์: ข้อมูลที่เราสร้างจากข้อมูลอื่น

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

ข้อมูลไม่มีโครงสร้าง: สิ่งที่ใส่ในแถวไม่ได้

เอกสาร PDF รูปภาพ เสียง วิดีโอ อีเมล บทถอดความ บทความฐานความรู้ ที่ Steve Trucking คือรูปถ่ายการจัดส่ง: ราวสี่รูปต่อการจัดส่ง มากกว่านั้นถ้ามีการติดตั้ง สี่ถึงห้าล้านรูปต่อปี รูปถ่ายไม่ใช่แค่อีกฟิลด์หนึ่ง มันใหญ่ อาจเห็นภายในบ้านของใครสักคน มีกฎการเก็บรักษาของตัวเอง และถูกค้นหาต่างออกไป ถ้าถูกค้นหาเลย

ประเภทนี้สำคัญขึ้นทุกปี เพราะตอนนี้ AI ทำสิ่งที่มีประโยชน์กับข้อมูลที่เคยอยู่นอกโมเดลแบบมีโครงสร้างได้ บทถอดความคือข้อมูล คู่มือ PDF คือข้อมูล รูปถ่ายการติดตั้งคือข้อมูล นั่นไม่ได้แปลว่ามันควรอยู่ใน core ของ Salesforce แต่แปลว่ามันควรอยู่บนภาพรวมระบบ

Click to enlarge

หกประเภท ประเภทละสี่คำถาม คำตอบเปลี่ยนไปตามแต่ละประเภท และนั่นคือประเด็น

ประเภทเป็นแค่ครึ่งหนึ่งของคำถาม: ภาระงาน

การรู้ว่าเรามีข้อมูลประเภทไหนยังไม่พอ ผมยังอยากรู้ว่าเรากำลังทำอะไรกับมัน ภาระงานสามแบบสำคัญตรงนี้ และการสับสนระหว่างมันทำให้เกิดสถาปัตยกรรมที่แย่

เชิงปฏิบัติการ: ดำเนินธุรกิจ ผู้จัดการเดินรถอัปเดตการจัดส่ง ทีมจัดส่งปิดจุดแวะ เจ้าหน้าที่เปิดเคส การอ่านและเขียนเล็กๆ จำนวนมาก: หาสิ่งนี้ อัปเดตสิ่งนั้น แสดงจุดแวะของวันนี้ นี่คือ OLTP (online transaction processing การประมวลผลธุรกรรมออนไลน์) และ Salesforce เก่งเรื่องนี้มาก มันคือที่ที่ผู้ดูแลระบบและนักพัฒนาใช้ชีวิตอยู่

เชิงวิเคราะห์: เข้าใจธุรกิจ ทุกการจัดส่งในห้าปี จัดกลุ่มตามพันธมิตรและ DC เปรียบเทียบปีต่อปี เชื่อมกับข้อมูลการเงิน ตอนนี้เรากำลังสแกนและรวมยอด นี่คือ OLAP (online analytical processing การประมวลผลเชิงวิเคราะห์ออนไลน์) และมันคือสิ่งที่คลังข้อมูล lakehouse และแพลตฟอร์มการวิเคราะห์ถูกสร้างมาเพื่อทำ พูดง่ายๆ: org ดำเนินธุรกิจ คลังข้อมูลและ data lake วิเคราะห์ธุรกิจ ความผิดพลาดคลาสสิกคือการวางภาระงานนั้นบนแพลตฟอร์มเชิงปฏิบัติการแล้วแปลกใจเมื่อเลขศูนย์เพิ่มขึ้น ถ้ามีคนต้องการสแกนประวัติจำนวนมหาศาลซ้ำๆ อย่าถือว่ามันเป็น “แค่อีกรายงานหนึ่ง” ถามว่ามันคือแพลตฟอร์มที่ถูกต้องหรือไม่ ส่วนที่ 2 จะกลับมาพูดเรื่องนี้ใน การออกแบบเพื่อรองรับขนาด (coming soon) (อย่าทำให้ core เป็นคลังข้อมูลของคุณ) และส่วนที่ 3 แสดงวิธีสร้างโครงสร้างเชิงวิเคราะห์ใน เหนือกว่าเชิงสัมพันธ์ (coming soon)

สตรีมมิง: ข้อมูลที่กำลังเคลื่อนที่ เหตุการณ์ เทเลเมทรี การเปลี่ยนสถานะ ค่าจากเซนเซอร์ รถบรรทุกของ Steve Trucking ส่งค่า GPS ราว 200,000 ค่าต่อวัน ผู้จัดการเดินรถสนใจว่ารถคัน 217 อยู่ที่ไหนตอนนี้ Salesforce ต้องเก็บทุกค่าทีละนาทีจากรถทุกคันไหม? อาจไม่ “ตอนนี้อยู่ไหน?” กับ “แนวโน้มประสิทธิภาพเส้นทางไตรมาสที่แล้วเป็นอย่างไร?” มาจากแหล่งเดียวกันและนำไปสู่การตัดสินใจเรื่องการจัดเก็บที่ต่างกันโดยสิ้นเชิง

ต้องเคลื่อนที่เร็วแค่ไหน?

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

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

คำถามสี่ข้อเบื้องหลังหมวดหมู่

คุณไม่ต้องเดินไปประกาศว่า “นี่คือข้อมูลธุรกรรม!” การจัดประเภทมีไว้เพื่อกระตุ้นคำถามสี่ข้อเกี่ยวกับชุดข้อมูลสำคัญทุกชุด:

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

คำถามสี่ข้อนั้นบอกผมได้มากกว่า “Salesforce เก็บสิ่งนี้ได้ไหม?” มาก และมันรวบรวมสิ่งที่เราเรียนมาแล้ว: ความเป็นเจ้าของ วงจรชีวิต จำนวนเลขศูนย์ และที่ที่ข้อมูลอยู่

ธุรกิจเดียวสร้างข้อมูลทุกประเภท

ที่ Steve Trucking พันธมิตรค้าปลีกคือข้อมูลหลัก คำศัพท์สถานะคือข้อมูลอ้างอิง การจัดส่งแต่ละครั้งคือข้อมูลธุรกรรม คำนิยามฟิลด์ของมันคือเมทาดาทา สกอร์การ์ดความตรงเวลาห้าปีคือข้อมูลเชิงวิเคราะห์ รูปถ่ายการติดตั้งคือข้อมูลไม่มีโครงสร้าง และฟีด GPS คือสตรีมมิง ทั้งหมดคือ “ข้อมูลของ Steve Trucking” ไม่มีสิ่งใดในนั้นแปลว่ามันควรอยู่ในฐานข้อมูลเดียวกัน นั่นคือการเปลี่ยนมุมมอง

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

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

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

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

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

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, พิมพ์ครั้งที่ 2 (2017) (ภาษาอังกฤษ): เอกสารอ้างอิงมาตรฐานสำหรับหมวดหมู่ข้อมูลและการจัดการข้อมูล
• บรีฟ ของ Steve Trucking ส่วนที่ 4 (ปริมาณ)