การเลือกชุดข้อมูลสำหรับ Data Governance ด้วย Data Architecture
ปัญหาอย่างหนึ่งของธรรมาภิบาลข้อมูล คือ “เราไม่มั่นใจว่า ข้อมูลไหนบ้างที่จะเป็นชุดข้อมูลภายใต้การกำกับดูแลข้อมูล” เราอาจพูดได้ว่า “เราต้องทำทุกชุดข้อมูลของทั้งองค์กรโดยไม่ขึ้นกับรูปแบบข้อมูล” แต่ในความจริงที่หลายๆ องค์กรเผชิญอยู่คือ การลงมือทำให้ครบทุกชุดข้อมูลนั้น ต้องอาศัย resources มากมาย ทั้ง คน เงิน และเวลา บทความนี้เราจะไม่พูดถึงธรรมาภิบาลแบบอุดมคติที่มุ่งหวังให้ออกมาดี เพียงชั่วข้ามคืน เราจะชวนคุยถึงธรรมาภิบาลข้อมูลแบบจับต้องได้ แม้ว่าอาจไม่ได้ดีที่สุดในตอนนี้ แต่เป็นมัน practical และพัฒนาต่อได้อย่างยั่งยืนครับ
ธรรมาภิบาลข้อมูลเป็นงานเกี่ยวกับอะไร
ธรรมาภิบาลข้อมูลคือ การกำกับดูแลข้อมูล แม้ว่าชื่อจะเป็นการกำกับที่ตัวข้อมูล แต่ตัวข้อมูลไม่ได้ถูก “ควบคุม” โดยธรรมาภิบาลข้อมูลโดยตรงครับ ธรรมาภิบาลข้อมูลใช้นโยบาย (Policy) เป็นเครื่องมือในการ “ควบคุม” การจัดการข้อมูล (Data Management) โดยคาดหวังว่า ข้อมูลจะดีขึ้นจากการที่ทุกคนในองค์กรได้จัดการข้อมูลที่เป็นไปปฏิบัติตามนโยบายอย่างจริงจังครับ ซึ่งนั่นหมายความว่า
ธรรมาภิบาลข้อมูล ควบคุม การจัดการข้อมูล และ การจัดการข้อมูล ควบคุม ข้อมูล และแน่นอนว่า การจัดการข้อมูลจะไม่เกิดขึ้นเลย ถ้าคนไม่ลงมือทำ ไม่มีพฤติกรรมใดๆ กับข้อมูล ด้วยเหตุนี้ ธรรมาภิบาลข้อมูล จึงเป็นงานที่ต้องใช้นโยบายข้อมูลไปควบคุมพฤติกรรมของคนในการจัดการข้อมูลครับ
การกำหนดชุดข้อมูล และประเด็นปัญหา
ตามหลักการทั่วไป การกำหนดชุดข้อมูลเป็นการนำข้อมูลมาจัดชุด โดยแต่ละชุดข้อมูลจะอยู่ภายใต้การกำกับดูแลข้อมูล การกำกับดูแลข้อมูลเป็นการกำหนดขอบเขตพฤติกรรมของคนในการจัดการข้อมูลให้อยู่ในขอบเขตตามกฎหมาย ระเบียบ และอื่นๆ ที่องค์กรอยู่ภายใต้บังคับ (Regulations) DMBoK [1] ได้นำเสนอการกำกับดูแลข้อมูลไว้ 2 แนวทาง คือ (1) การกำกับดูแลข้อมูลด้วยการกำหนดขอบเขตพฤติกรรมของคนในการจัดการข้อมูลตาม “วงจรชีวิตของข้อมูล” (Data lifecycle) (2) การกำกับดูแลข้อมูลด้วยการกำหนดขอบเขตพฤติกรรมของคนในการจัดการข้อมูลตามแนวทางการจัดการข้อมูล (Data management) ตั้งแต่ Metadata จน ถึง Data warehousing and Business intelligence ผู้เขียนเห็นว่าทั้ง 2 แนวทางนั้น อยู่ในขอบเขตที่ค่อนข้างชัดเจน คือ data lifecycle 6 ขั้นตอน และ data management อีก 10 มิติ ครับ แต่ที่มีขอบเขตไม่ชัดเจนคือ ข้อมูลใดที่จะถูกนำมาจัดเป็นชุด และจำนวนชุดข้อมูลจะเกิดผลกระทบอะไรบ้าง?
สมมติว่า ทั้งองค์กรมีข้อมูลทั้งหมด 20 ชุด (20 dataset) ที่จะถูกกำกับ และมีการกำกับครบทั้ง 10 มิติ และ 6 ขั้นตอน คิดคร่าวๆ ว่า task ที่เกิดขึ้นทั้งหมดอาจสูงถึง 20x10x6 = 1200 tasks!!! … นี่ยังไม่ได้คิดแยก elements ของแต่ละ task ออกมานะ
ด้วยเหตุของจำนวนชุดข้อมูล และมิติการจัดการข้อมูล รวมถึงขั้นตอนตามวงจรชีวิตที่ต้องการกำกับข้างต้น ส่งผลต่อปริมาณและความซับซ้อนของงานด้านการกำกับดูแลข้อมูล หากเราไม่มี resource เพียงพอที่จะสานฝันการกำกับดูแลข้อมูลให้เสร็จสิ้นภายระยะเวลาอันสั้น หรือเสร็จสิ้นภายในโปรเจคเดียว การเลือกที่จะกำกับข้อมูลทั้งหมด จึงไม่ practical
ทางออกคือ เราต้องกำหนดชุดข้อมูล ด้วยการเลือกข้อมูลที่สำคัญมาจัดชุดก่อน หลักการทั่วไปในการตัดสินว่าข้อมูลไหนสำคัญกับองค์กร อาจหยิบยกเรื่อง รายได้ ต้นทุน ลูกค้า และผลิตภัณฑ์ มาเป็นหลักในการตัดสินก็ได้ แต่หากอยากจะคิดให้ละเอียดขึ้น ผู้เขียนขอแนะนำให้ตั้งคำถามว่า “เราอยู่ภายใต้บังคับของ กฎหมาย ระเบียบ ข้อบังคับ อื่นๆ รวมถึงพันธะสัญญาต่างๆ กับภายนอกหรือลูกค้า ไว้อย่างไรบ้าง และสิ่งเหล่านั้นได้กำหนดหลักเกณฑ์การเลือกไว้หรือไม่? … ถ้ากำหนด เราต้องทำตามที่เค้ากำหนดก่อนครับ”
กรณีภาครัฐไทย ผู้เขียนตอบให้เลยว่า ภาครัฐอยู่ภายใต้บังคับของ มรด.3–1 : 2565 ว่าด้วยแนวทางการจัดทำบัญชีข้อมูลภาครัฐ ที่ได้กำหนดหลักเกณฑ์การเลือกชุดสำคัญไว้แล้ว[2] กรณีภาคเอกชน อาจมีคำตอบที่หลากหลาย แต่ไม่ว่าคำตอบใด ธุรกิจจะไม่สามารถอยู่รอดได้เลย ถ้าลูกค้าไม่เอา ขายของหรือให้บริการไม่ได้ ไม่มีรายได้เข้ากิจการ หรือต้นทุนเยอะเหลือเกิน … คือ ผู้เขียนกำลังแนะนำว่า เอกชนต้องกำหนดชุดข้อมูลที่เป็นไปตามเกณฑ์ต่างๆ ที่เอกชนอยู่ภายใต้บังคับ และยังจำเป็นต้องกำหนด “ชุดข้อมูลที่สร้างคุณค่าให้กับธุรกิจ” อีกด้วย
การกำหนดชุดข้อมูลที่สร้างคุณค่าให้กับธุรกิจ
(1) กรณีองค์กรของท่านมีการทำ EA (Enterprise Architecture) ไว้ดีแล้ว ให้คัดเลือก Business domain ที่สร้างคุณค่าให้กับธุรกิจ แล้วใช้ Subject area diagram ภายใต้ domain นั้นไปทำต่อในข้อ (3) ได้เลย
(2) กรณีที่ยังไม่ได้ทำ EA ให้เลือก Business domain ที่สร้างคุณค่าให้กับธุรกิจ แล้วจึงจัดทำ diagram ที่ประกอบด้วย 1 หรือหลายๆ Subject area ภายใต้ Business domain นั้น
(3) หลังจากได้รับ Subject area diagram ตามข้อ (1) หรือ (2) แล้ว ข้อมูลที่จะนำมาจัดชุด (Pieces of data) คือ Attribute value ที่อธิบาย Business entity ภายใน Subject area diagram
(4) รวบรวม Attribute values เข้าเป็นชุด เรียกว่า ชุดข้อมูล (Dataset) ในทางปฏิบัติอาจไม่มีขั้นตอนการรวบรวมก็ได้ เนื่องจาก Business entity 1 ตัว คือ 1 dataset อยู่แล้ว ซึ่งเป็นไปได้อย่างมากว่า แต่ละ dataset ก็จะประกอบด้วย tables หลายๆ ตัวใน database ขององค์กร
ทำไมต้อง Business Domain .. คำตอบเกี่ยวข้องกับ Data Architecture
Architecture เป็นการอธิบายถึงสิ่งที่ “ต้องการจะสร้าง” หรืออธิบาย “ผลจากการสร้าง” โดยที่ “สิ่ง” นั้นจะเป็นอะไรก็ขึ้นอยู่กับว่าเรานำคำว่า Architecture ไปใช้กับบริบทอะไร กรณีนำไปใช้กับ data ก็หมายความว่า เรากำลังอธิบายว่า data ที่มีอยู่ (As-is) และอาจมี data ที่คาดหวัง (To-be) เป็นอย่างไรด้วย
การอธิบาย data มักเป็นการอธิบายในขอบเขต Business domain ด้วยแบบจำลอง (Model) ที่อยู่ในรูปแบบ Subject area diagram และ Data flow diagram ที่ช่วยให้องค์กรรับประโยชน์ ดังนี้
(1) ทราบว่ามีข้อมูลอะไรบ้างใน Subject area ภายใต้ Business domain หนึ่งๆ
(2) ทราบว่าข้อมูลไหนมีความสำคัญมากน้อยอย่างไรจาก Data flow diagram เช่น ทราบว่า entity ไหนคือ master data หรือ reference data
(3) ทราบกิจกรรมที่เกิดขึ้นในวงจรชีวิตของข้อมูล จาก Data flow diagram เช่น อ่านอย่างเดียว หรือ อ่านและแก้ไขได้ เป็นต้น
(4) ช่วยระบุเจ้าของและผู้รับผิดชอบในการดูแลชุดข้อมูลต่างๆ ได้อย่างชัดเจน
ดังนี้แล้ว Business Domain จึงเป็นจุดเริ่มต้นที่ดีในการกำหนดขอบเขตของธุรกิจ และด้วยการใช้ Subject area diagram รวมถึง Data flow diagram ทำให้เรามองเห็น Business entity ได้ครบถ้วนภายใต้ขอบเขตโตเมนที่เราเลือก
เราเลือก Business Domain อย่างไร แล้วต้องทำอะไรต่อ จึงจะได้ชุดข้อมูล
การเลือก Business domain ที่สร้างคุณค่าให้ธุรกิจ อาจใช้หลักเกณฑ์ต่างๆ ตามลำดับดังนี้
(1) ความสอดคล้องกับกลยุทธ์และเป้าหมายขององค์กร
(2) ผลกระทบต่อรายได้และผลกำไร
(3) ความสำคัญต่อลูกค้าและตลาด
(4) ความเสี่ยงและผลกระทบเชิงลบ
(5) ความพร้อมและความสามารถในการดำเนินการ
และเมื่อเลือก Business domain แล้ว จึงลงมือออกแบบ Subject area diagram
Subject area diagram เป็นแผนภาพที่อธิบายว่าใน business domain หนึ่งๆ ประกอบด้วย area อะไรบ้าง (อาจมากกว่า 1 area) ซึ่งเราอาจตีความว่า 1 area = 1 business function ก็ได้ ดังนั้น 1 subject area ก็จะเป็นการอธิบายว่า มีฟังก์ชั่นการดำเนินงานอะไร (business function) ให้บรรลุผลสำเร็จได้ ตัวอย่างเช่น Business domain: “การบริหารห่วงโซ่อุปทาน” (Supply Chain Management) ประกอบด้วยหลายๆ Subject area/Business function อาทิเช่น Business function: การจัดซื้อ (Procurement), Business function: การบริหารสินค้าคงคลัง (Inventory Management) เป็นต้น จากตัวอย่างที่ยกมา มี 2 Subject areas
การเขียน Subject area diagram ให้ focus ที่แต่ละ Subject area โดย 1 Subject area ประกอบด้วยหลายๆ business entity และ relationship ระหว่าง entity ซึ่งแม้ว่า entity จะไม่ใช่ข้อมูล แต่เป็นสิ่งสำคัญต่อการดำเนินธุรกิจ ซึ่งมี attribute ที่สามารถอธิบายด้วยข้อมูลได้ เช่น entity ลูกค้า อธิบายด้วย attribute: ชื่อ และ ID , entity ใบสั่งซื้อ อธิบายด้วย attribute: ชื่อสินค้าที่สั่งซื้อ จำนวน และ ID, entity สินค้า อธิบายด้วย attribute: ชื่อสินค้า ราคาต่อหน่วย และ ID เป็นต้น เงื่อนไขสำคัญคือ business entity หนึ่งๆ จะต้องอยู่ใน Subject area หนึ่งเท่านั้น และสามารถมี relationship ระหว่าง entity ภายใน area เดียวกัน หรือข้าม area ได้ [1] ตัวอย่างการเขียน Subject area diagram สำหรับ Business domain: “การบริหารห่วงโซ่อุปทาน” ตามรูปที่ 1
ตามรูปที่ 1 มี Business entity 7 ตัว ซึ่งทั้งหมดอธิบายได้ด้วยข้อมูล อย่างเช่น Sales Order ประกอบด้วย attribute: Order Number, Customer ID, Item, Total Amount เป็นต้น ดังนั้น เราจึงสามารถสรุปได้ว่า Business domain: “การบริหารห่วงโซ่อุปทาน” ซึ่งประกอบด้วย 7 ชุดข้อมูล ประกอบด้วย Supplier, Purchase Plan, Purchase Order, Goods Receipt, Warehouse, Goods Issue และ Sales Order
สรุป
การกำหนดชุดข้อมูลเพื่อทำธรรมาภิบาลข้อมูลให้ได้ผลในทางปฏิบัติ องค์กรอาจเริ่มต้นจากการเลือกชุดข้อมูลที่สำคัญและสร้างคุณค่าให้ธุรกิจมาดำเนินการก่อน โดยกำหนดขอบเขตชุดข้อมูลจาก Business Domain ที่เกี่ยวข้อง และใช้ Subject Area Diagram เพื่อจัดชุดข้อมูลตาม Business Entity ต่างๆ
แม้วิธีการนี้จะยังไม่ครอบคลุมข้อมูลทั้งหมดขององค์กรในทันที แต่เป็นแนวทางที่ช่วยให้การทำธรรมาภิบาลข้อมูลเกิดผลเป็นรูปธรรมได้เร็วขึ้น และสามารถต่อยอดขยายสู่ชุดข้อมูลอื่นๆ ได้อย่างยั่งยืนในระยะถัดไป ทั้งนี้ยังต้องคำนึงถึงการปฏิบัติตามregulations ที่องค์กรอยู่ภายใต้บังคับ ควบคู่กันเสมอไปด้วย
👏 ปรบมือเพื่อแสดงความรู้สึกของคุณ
ขอบคุณมากครับผม
อ้างอิง
[1] “Data Managment Body of Knowledge: DMBoK”, DAMA, 2017
[2] “มรด.3–1:2565 ว่าด้วยแนวทางการจัดทําบัญชีข้อมูลภาครัฐ”, 2565
