การสร้างแบบจำลองข้อมูลเชิงแนวคิด: คู่มือปฏิบัติสำหรับทีมงาน

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

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

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

เหตุใดข้อมูลธุรกิจของคุณจึงรู้สึกเหมือนปริศนา

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

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

ทำให้ข้อสมมติฐานที่มองไม่เห็นปรากฏชัดเจน

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

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

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

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

ทำความเข้าใจแนวคิดหลักของการสร้างแบบจำลองข้อมูลเชิงแนวคิด

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

เริ่มต้นด้วย เอนทิตี (entities) คือ บุคคล วัตถุ เหตุการณ์ หรือแนวคิดที่ธุรกิจจำเป็นต้องพูดถึง ผู้ค้าปลีกรายหนึ่งอาจระบุ Customer, Order, Product และ Promotion สิ่งเหล่านี้ยังไม่ใช่ตารางฐานข้อมูล แต่เป็นแนวคิดทางธุรกิจที่มีความหมายซึ่งผู้คนสามารถจดจำและนิยามได้

ถัดมา ให้ระบุ แอตทริบิวต์ (attributes) ซึ่งเป็นคุณสมบัติที่ช่วยอธิบายเอนทิตี Customer อาจมีชื่อและสถานะลูกค้า ส่วน Order อาจมีวันที่สั่งซื้อและสถานะทางธุรกิจ แบบจำลองเชิงแนวคิดมักเน้นที่แอตทริบิวต์ที่ช่วยให้เข้าใจความหมายของเอนทิตีชัดเจนขึ้น มากกว่าการพยายามแจกแจงทุกฟิลด์ที่ระบบอาจจัดเก็บในที่สุด

เชื่อมโยงแนวคิดด้วยความสัมพันธ์

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

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

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

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

อธิบายแบบจำลองเอนทิตี-ความสัมพันธ์ (Entity-Relationship Model)

แบบจำลองเอนทิตี-ความสัมพันธ์ (Entity-Relationship หรือ ER model) ให้วิธีการแสดงภาพที่คุ้นเคยแก่ทีมงานในการนำเสนอเอนทิตี แอตทริบิวต์ และความสัมพันธ์ ลองพิจารณาผู้ค้าปลีกออนไลน์รายหนึ่ง Customer คือเอนทิตี Name คือแอตทริบิวต์ของ Customer และ “Customer places Order” คือความสัมพันธ์ แผนภาพช่วยทำให้แนวคิดเหล่านี้มองเห็นได้ในหน้าเดียว เพื่อให้เพื่อนร่วมงานสามารถหารือเกี่ยวกับโครงสร้างทางธุรกิจก่อนที่จะออกแบบฐานข้อมูล

Peter Chen นำเสนอโมเดล ER ของเขาในการประชุม International Conference on Very Large Data Bases ครั้งแรกเมื่อปี 1975 บทความของเขาได้รับการตีพิมพ์ในเดือนมีนาคม 1976 ในฉบับแรกของ ACM Transactions on Database Systems แนวทางของ Chen ช่วยให้การสื่อสารความต้องการข้อมูลด้วยภาษาทางธุรกิจทำได้ง่ายขึ้น ในขณะเดียวกันก็ยังคงเป็นพื้นฐานที่มีโครงสร้างสำหรับการออกแบบฐานข้อมูล (ประวัติของบทความและบริบทของการสร้างโมเดล ER)

อ่านไดอะแกรมในรูปแบบประโยคทางธุรกิจ

ไดอะแกรม ER แบบง่ายจะอ่านง่ายขึ้นหากคุณแปลงแต่ละการเชื่อมโยงให้เป็นประโยค “Customer places Order” อธิบายความสัมพันธ์หนึ่ง “Order contains Product” อธิบายอีกความสัมพันธ์หนึ่ง ชื่อของเอนทิตีระบุสิ่งที่ธุรกิจต้องการติดตาม ในขณะที่แอตทริบิวต์ให้รายละเอียดที่เป็นประโยชน์เกี่ยวกับแต่ละแนวคิด

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

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

โมเดล ER ยังคงมีประโยชน์เพราะมันเชื่อมโยงระหว่างบทสนทนาและการออกแบบเข้าด้วยกัน แนวคิดของมันมีอิทธิพลต่อไดอะแกรม entity-relationship, logical schema และงานด้านสถาปัตยกรรมข้อมูล สำหรับคู่มือปฏิบัติเกี่ยวกับการอ่านรูปแบบภาพนี้ โปรดดูที่ คำอธิบายไดอะแกรม entity-relationship รักษาให้ไดอะแกรมมุ่งเน้นไปที่การตัดสินใจที่ผู้คนต้องทำ แทนที่จะเปลี่ยนให้มันกลายเป็นรายการของทุกฟิลด์ในทุกระบบ

โมเดลข้อมูล Conceptual เทียบกับ Logical เทียบกับ Physical

ทีมงานมักใช้คำว่า “data model” เพื่ออธิบายการออกแบบในระดับรายละเอียดที่แตกต่างกัน การแยกระดับ conceptual, logical และ physical ออกจากกันช่วยให้เข้าใจได้ง่ายขึ้นว่าโมเดลแต่ละแบบตอบคำถามอะไร และใครควรเป็นผู้ตรวจสอบ

แนวคิดเดียว รายละเอียดที่เพิ่มขึ้น

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

โมเดลเชิงตรรกะ (logical model) เพิ่มโครงสร้างเข้าไป ทีมงานสามารถกำหนดแอตทริบิวต์เพิ่มเติม ทำให้ตัวระบุชัดเจนขึ้น และแก้ไขความสัมพันธ์ต่าง ๆ สำหรับการออกแบบที่ยังไม่ผูกติดกับแพลตฟอร์มฐานข้อมูลใดฐานข้อมูลหนึ่ง ในขั้นตอนนี้ กฎการออกแบบเชิงสัมพันธ์ (relational design) อาจเข้ามามีบทบาท ตัวอย่างเช่น การทำ normalization ช่วยระบุว่าคุณสมบัติใดควรอยู่กับเอนทิตีอื่น เพื่อไม่ให้การอัปเดตสร้างสำเนาข้อมูลที่ขัดแย้งกัน ในรีเลชัน OrderLine ที่ระบุด้วย OrderID และ ProductID นั้น ProductName ขึ้นอยู่กับ ProductID มากกว่าจะขึ้นอยู่กับคีย์ผสมทั้งหมด ดังนั้นจึงควรอยู่กับ Product แทนที่จะถูกทำซ้ำเป็นคุณสมบัติของ OrderLine (กฎและตัวอย่างของ normalization)

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

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

ตัวอย่างเชิงปฏิบัติของการสร้างโมเดลเชิงแนวคิด

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

เริ่มต้นจากคำถามทางธุรกิจ

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

ระบุเอนทิตีที่น่าจะเกี่ยวข้อง:

• Customer บุคคลหรือองค์กรที่ทำการสั่งซื้อ
• Order เหตุการณ์การซื้อที่ร้านค้าปลีกต้องการวิเคราะห์
• Product สินค้าที่มีจำหน่าย
• Promotion ข้อเสนอที่กำหนดไว้พร้อมกฎทางธุรกิจ

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

จับคู่ความสัมพันธ์และทดสอบสมมติฐาน

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

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

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

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

ทำไมแบบจำลองเชิงแนวคิดถึงถูกทิ้งร้างและวิธีหลีกเลี่ยง

การสร้างแบบจำลองอย่างเป็นทางการอาจฟังดูมีคุณค่าในการประชุมวางแผน แต่ก็ยังสามารถหายไปได้เมื่องานประจำวันเข้ามาครอบงำ การศึกษาผู้เชี่ยวชาญด้านฐานข้อมูล 485 คน เสริมด้วยการสัมภาษณ์ 34 ครั้ง พบว่ามีเพียงน้อยกว่า 40% ที่ใช้การสร้างแบบจำลองข้อมูลเชิงแนวคิดอย่างเป็นทางการอย่างสม่ำเสมอ แม้ว่าพวกเขาจะเชื่อว่ามันสามารถช่วยได้ การอภิปรายบนไวท์บอร์ดเพียงอย่างเดียวถูกรายงานว่าเป็นทางเลือกทดแทนโดย 45.1% ในขณะที่การขาดเวลาเป็นอุปสรรคสำหรับ 42.1% (การศึกษาแนวปฏิบัติและการนำการสร้างแบบจำลองไปใช้)

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

สร้างแบบจำลองขั้นต่ำที่ใช้งานได้จริง

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

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

โมเดลหนึ่งจะมีคุณค่าก็ต่อเมื่อมันช่วยคลี่คลายการตัดสินใจ ไม่ใช่เพียงเพราะมันเติมเต็มหน้ากระดาษ

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

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

โมเดลเชิงแนวคิดขับเคลื่อนการวิเคราะห์ข้อมูลและ AI สมัยใหม่ได้อย่างไร

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

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

ให้คำนิยามมีที่อยู่ที่ตรวจสอบย้อนกลับได้

การสร้างโมเดลเชิงแนวคิดยังสนับสนุนการกำกับดูแลเมทาดาทาด้วย เมทาดาทาคือข้อมูลเกี่ยวกับข้อมูล เช่น คำนิยามทางธุรกิจ เจ้าของ ค่าที่ใช้ได้ หรือการแมปแหล่งที่มา มาตรฐาน ISO/IEC 11179-3:2023 กำหนดเมตาโมเดลสำหรับทะเบียนเมทาดาทา ซึ่งมีโครงสร้างสำหรับการระบุ การนิยาม การลงทะเบียน และการจัดประเภทรายการที่สามารถนำกลับมาใช้ใหม่ได้ ส่วนขยายที่เกี่ยวข้องครอบคลุมแนวคิดองค์ประกอบข้อมูล โดเมนเชิงแนวคิด และโดเมนค่า (ISO/IEC 11179-3:2023)

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

รากฐานนี้มีความสำคัญมากขึ้นเรื่อยๆ เมื่อองค์กรต่างๆ ใช้ semantic layer การรายงานอัตโนมัติ และการวิเคราะห์ที่ได้รับความช่วยเหลือจาก AI งานวิจัยเกี่ยวกับการสร้างแบบจำลองเชิงแนวคิดชี้ให้เห็นถึงความท้าทายด้านการตัดสินใจที่เกิดขึ้นซ้ำๆ โดยเฉพาะการตัดสินใจเลือกประเภทความสัมพันธ์ การกำหนด cardinality และการตั้งชื่อความสัมพันธ์ คำขอที่เป็นภาษาธรรมชาติสามารถซ่อนทางเลือกเหล่านั้นไว้ได้ เช่น “ลูกค้าที่ซื้อสินค้าในช่วงโปรโมชั่น” ยังคงเปิดคำถามว่าอะไรนับเป็นการซื้อ วันที่ใดที่กำหนด “ช่วง” นั้น และลูกค้าสามารถเข้าเกณฑ์ได้ผ่านหลายคำสั่งซื้อหรือไม่ (งานวิจัยเกี่ยวกับความท้าทายในการสร้างแบบจำลองเชิงแนวคิด)

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

ประเด็นสำคัญและขั้นตอนต่อไปของคุณ

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

เริ่มต้นด้วยคำถามทางธุรกิจที่เกิดขึ้นจริงหนึ่งข้อ เช่น เหตุใดสองทีมจึงรายงานรายได้แตกต่างกัน จากนั้น:

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

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

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