Data Lake ไม่ใช่โกดังข้อมูล แต่คือระบบความไว้วางใจของมหาวิทยาลัย
ผมมีโอกาสบรรยายและแลกเปลี่ยนเรื่อง “การพัฒนาและบริหารจัดการระบบคลังข้อมูลขนาดใหญ่ มหาวิทยาลัยสงขลานครินทร์” ณ สำนักนวัตกรรมดิจิทัลและระบบอัจฉริยะ มหาวิทยาลัยสงขลานครินทร์
ประเด็นตั้งต้นคือ Data Lake ไม่ควรเริ่มจากคำถามว่า “จะใช้เทคโนโลยีอะไร” หรือ “จะทำ Dashboard แบบไหน” แต่ควรเริ่มจากว่า มหาวิทยาลัยต้องการใช้ข้อมูลเพื่อตัดสินใจเรื่องอะไร ใครเป็นผู้ใช้ และจะทำให้ข้อมูลนั้นเชื่อถือได้อย่างไร
ข้อมูลจำนวนมากไม่เท่ากับข้อมูลที่พร้อมใช้
มหาวิทยาลัยอาจมีข้อมูลสะสมจากหลายระบบ แต่หากไม่รู้ว่าข้อมูลมาจากไหน ใครรับผิดชอบ นิยามตรงกันหรือไม่ ผ่านการตรวจสอบอะไร อัปเดตเมื่อใด และมีข้อจำกัดอย่างไร จำนวนข้อมูลที่มากขึ้นก็อาจเพียงทำให้ความไม่แน่นอนถูกซ่อนไว้ในโครงสร้างที่ใหญ่ขึ้น
ตัวเลขบน Dashboard ต้องย้อนกลับไปยังระบบต้นทางและกติกาการคำนวณได้ มิฉะนั้นเมื่อสองรายงานให้คำตอบไม่ตรงกัน องค์กรจะเสียเวลาเถียงกันว่าตัวเลขใครถูก แทนที่จะใช้ข้อมูลตัดสินใจ
Data Lake, API และ Dashboard ทำหน้าที่ต่างกัน
Data Lake เป็นพื้นที่รวมและจัดการข้อมูลจากหลายแหล่ง แต่ไม่ควรถูกมองว่าเป็นปลายทางของโครงการ Data API ทำให้ข้อมูลที่ผ่านการจัดการแล้วถูกเรียกใช้ด้วยข้อตกลงที่ชัด ส่วน Dashboard เป็นเพียงหนึ่งในช่องทางที่นำข้อมูลไปช่วยคนมองเห็นสถานการณ์และตัดสินใจ
หากไม่มีชั้นของนิยาม คุณภาพ เจ้าของข้อมูล และสิทธิการเข้าถึง การสร้าง Dashboard เพิ่มอาจเพียงทำให้ข้อมูลที่ยังไม่น่าเชื่อถือดูสวยและแพร่กระจายเร็วขึ้น
Data Governance ต้องอยู่ในงาน ไม่ใช่อยู่เฉพาะในคณะกรรมการ
ธรรมาภิบาลข้อมูลควรกำหนดบทบาทว่าใครเป็นเจ้าของข้อมูล ใครดูแลเชิงปฏิบัติ ใครอนุมัติการเข้าถึง ใครแก้เมื่อคุณภาพมีปัญหา และใครอธิบายความหมายของตัวชี้วัด แต่การมีรายชื่อบทบาทยังไม่พอ หากกระบวนการจริงไม่ทำให้คนเหล่านั้นสามารถรับผิดชอบได้
กติกาควรถูกฝังใน workflow ตั้งแต่จุดที่ข้อมูลเกิด การตรวจสอบ การเปลี่ยนแปลง การเผยแพร่ และการใช้งาน เพื่อให้ governance เป็นส่วนหนึ่งของระบบ ไม่ใช่เอกสารที่เปิดอ่านเฉพาะเวลาตรวจประเมิน
Data Quality เป็นคุณสมบัติที่ผูกกับวัตถุประสงค์
ข้อมูลไม่ได้ “มีคุณภาพ” แบบเดียวในทุกบริบท ความถูกต้อง ความครบถ้วน ความทันเวลา ความสอดคล้อง และความไม่ซ้ำมีความสำคัญต่างกันตามการใช้งาน ข้อมูลที่เพียงพอสำหรับรายงานแนวโน้มอาจไม่เพียงพอสำหรับตัดสินสิทธิของบุคคลหรือจัดสรรงบประมาณ
การตรวจคุณภาพจึงต้องเริ่มจาก decision requirement ว่าความผิดพลาดแบบใดสร้างความเสียหาย ใครตรวจพบได้เร็วที่สุด และเมื่อข้อมูลไม่ผ่านเกณฑ์ ระบบควรหยุด แจ้งเตือน หรือแสดงข้อจำกัดอย่างไร
อย่าแก้ปัญหาข้อมูลด้วยการเพิ่มภาระกรอกซ้ำ
ข้อมูลที่ดีควรเกิดจากการทำงานจริงให้มากที่สุด ไม่ใช่ขอให้บุคลากรคัดลอกข้อมูลเดิมไปกรอกอีกระบบเพื่อทำรายงาน หากระบบปฏิบัติงานเป็นแหล่งต้นทางที่เชื่อถือได้ การเชื่อมต่อและปรับปรุง workflow จะลดทั้งภาระคนและความคลาดเคลื่อนจากการบันทึกซ้ำ
การออกแบบ dataflow จึงต้องเดินคู่กับ workflow transformation เราไม่ควรทำให้คนทำงานเพิ่มเพียงเพื่อทำให้คลังข้อมูลดูครบ แต่ควรทำให้การทำงานปกติสร้างข้อมูลที่นำไปใช้ต่อได้โดยธรรมชาติ
เริ่มจาก Data Product หนึ่งชิ้นที่ใช้จริง
มหาวิทยาลัยไม่จำเป็นต้องทำทุกอย่างพร้อมกัน วิธีเริ่มที่เรียนรู้ได้เร็วคือเลือกโจทย์การตัดสินใจสำคัญหนึ่งเรื่อง ระบุผู้ใช้และการตัดสินใจที่ต้องเกิด แล้วพัฒนา Data Product ที่มีเจ้าของ นิยาม แหล่งที่มา เกณฑ์คุณภาพ และรอบการอัปเดตชัดเจน
จากนั้นเชื่อมผ่าน API นำไปใช้ในรายงานหรือ Dashboard จริง เก็บปัญหาจากผู้ใช้ ตรวจว่าการตัดสินใจดีขึ้นหรือไม่ แล้วค่อยขยายไปยังโจทย์อื่น วิธีนี้สร้างทั้งของที่ใช้ได้และความสามารถขององค์กรไปพร้อมกัน
Data Lake คือข้อตกลงเรื่องความไว้วางใจ
คุณค่าของ Data Lake ไม่ได้อยู่ที่ความจุหรือจำนวนระบบที่เชื่อมต่อ แต่อยู่ที่การทำให้คนต่างหน่วยงานสามารถใช้ข้อมูลร่วมกันโดยเข้าใจความหมาย เห็นข้อจำกัด ตรวจสอบที่มา และรู้ว่าเมื่อเกิดปัญหาต้องกลับไปหาใคร
ในความหมายนี้ Data Lake คือการสร้าง “ระบบความไว้วางใจในข้อมูล” ร่วมกันทั้งมหาวิทยาลัย เทคโนโลยีทำให้ระบบเป็นไปได้ แต่ความไว้วางใจเกิดจากความรับผิดชอบ กระบวนการ และหลักฐานที่ทุกฝ่ายตรวจสอบร่วมกันได้