BzInsight

ทีมงานในโครงการด้าน BI ที่ผมทำงานด้วยนี่จัดกลุ่มไว้เป็นสามกลุ่ม ตามความพร้อมแต่ละด้าน คือ ด้าน technical, user และ client  ทีมงานด้านเทคนิคคือฝ่าย IT ที่ดูแลงานออกแบบและสร้างระบบ ผู้นำด้านผู้ใช้จะเป็นตัวแทนด้าน business requirements หรือการปรับเปลี่ยนกระบวนการทำงานต่างๆ (work processes) เพื่อให้การนำระบบงานเข้าไปใช้ให้เกิดประโยชน์สูงสุด ส่วนกลุ่มที่ติดต่อกับผู้บริหารก็ทำหน้าที่ผู้จัดการโครงการโดยทั่วไป คอยสื่อสารกับผู้บริการและผู้เกี่ยวข้องอื่นๆ

หนึ่งในงานชิ้นใหญ่เลยคือการเตรียมข้อมูลอ้างอิง หรือ master data ซึ่งจากที่เคยคุยให้ฟังแล้วว่า การสำรวจความพร้อมของ master data ถือเป็นเรื่องจำเป็นสำหรับการทำระบบ Business Intelligence เนื้องานกว่าครึ่งในโครงการ BI จะเกี่ยวข้องกับการจัดเตรียมข้อมูลอ้างอิง (ไม่นับรวมกับการพัฒนาระบบนะครับ)

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

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

1. นิยามของข้อมูลอ้างอิงที่ไม่ชัดเจน หรือไม่สอดคล้องกัน อย่างข้อมูลเกี่ยวกับลูกค้า อาจจะมี attribute หนึ่งที่บอกว่าลูกค้ารายนี้เป็นลูกค้าชั้นดีหรือไม่ ซึ่งในแง่เทคนิคแล้วง่ายมาก ถ้าเป็นลูกค้าชั้นดี attribute top_customer มีค่าเป็น Y ถ้ามีค่าอื่นแสดงว่าไม่ใช่ลูกค้าชั้นดี ปัญหาส่วนใหญ่จะอยู่ที่ หัวหน้าแต่ละแผนก ให้นิยามของลูกค้าชั้นดีแตกต่างกัน ฝ่ายขายอาจจะดูที่ยอดขาย ในขณะที่ฝ่ายการเงินดูที่ประวัติการชำระเงิน
2. ขั้นตอนการทำงานในการ CRUD (Create-Read-Update-Delete) ของข้อมูลอ้างอิง ไม่ได้มีการกำหนดไว้อย่างชัดเจน ลูกค้าอาจจะแค่เปลี่ยนชื่อบริษัท (แต่ยังเป็นลูกค้ารายเดิม) ก็กลายเป็นว่ามีการสร้าง customer id รายใหม่เข้ามาในระบบ ทั้งนี้เพราะเซลล์ซึ่งดูแลลูกค้ารายนี้ ไม่ได้แจ้งกับเจ้าหน้าที่ที่ทำหน้าที่บันทึกข้อมูล ว่าลูกค้ารายนี้มีประวัติอยู่ก่อนแล้ว

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

คราวที่แล้วเอาสไลด์ชุด Data Warehouse 101 มาฝาก วันนี้เป็นบทที่สองจากหนังสือเล่มเดิมนั่นแหละครับ ที่จริงก็ทำไว้แค่สองบทเท่านั้นเอง เป็นการปูพื้น บทที่สองนี้มีชื่อเรียกโดยเฉพาะว่า Business Dimensional Life Cycle เป็นกระบวนการจัดการโครงการที่ทาง The Kimball Group คิดขึ้นมา  มาจนถึงปัจจุบัน วิธีการนี้ก็ไม่ได้แปลกใหม่อะไรเลย แต่ผมคิดว่ายังมีประโยชน์สำหรับคนที่เริ่มทำงานเกี่ยวกับ data warehouse project เป็นครั้งแรก เพราะทำให้มองเห็นภาพได้ชัดเจนว่า โดยรวมๆ แล้ว มีอะไรที่จำเป็นต้องทำบ้าง

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

เนื้อหาที่ผมเอามาฝากวันนี้ เป็น webcast ที่จัดขึ้นโดย BIWA (Business Intelligence, Warehousing, and Analytic Special Interest Group) ซึ่งเป็นองค์กรที่ Oracle ให้การสนับสนุน สมัครสมาชิกได้ฟรีนะครับ ก็มีการจัดสัมนา พูดคุย แลกเปลี่ยนความรู้กัน ชื่อ webcast นี้คือ Best Practices for Managing Successful BI Projects

Download PDF (1.7 MB)
Download recorded webcast (17.8 MB - เป็น Exe ที่ฝัง Java โปรแกรมเอาไว้ แต่ปลอดภัยครับ ผมลองฟังดูแล้ว)

ประเด็นที่น่าสนใจประกอบไปด้วย

• เน้นไปที่การทำความเข้าใจกับผู้ใช้ว่า ผู้ใช้ด้าน BI ยังไม่รู้หรอกว่าเขาต้องการอะไรในช่วงแรกๆ การเน้นความยืดหยุ่นให้ requirements เปลี่ยนแปลงไปได้ จึงมีความจำเป็นมาก

• เน้นการทำระบบแบบแบ่งเป็นส่วนๆ (Phases) แต่ส่วนใช้เวลาสั้นๆ ไม่เกิน 120 วัน ทำ  Prototype

• ให้ความรู้กับผู้ใช้ นอกเหนือจากส่วนเครื่องมือหรือ tools ทึ่ใช้แล้ว บางทีการสอน OLAP เบื้องต้นก็สามารถช่วยได้มาก

• ออกแบบเผื่อสำหรับอนาคต แต่สร้างเฉพาะส่วนที่จำเป็นในปัจจุบัน

• ในแต่ละรอบของการทำซ้ำ หรือเริ่ม phase ใหม่ ให้รวบรวมสิ่งที่ทำพลาดไปในรอบก่อนหน้านั้น ในลักษณะ lessons learned

มีรายละเอียดย่อยๆ อีกหลายอย่างครับ อ่าน PDF อย่างเดียวก็ได้ประโยชน์แล้ว แต่ถ้าใครสะดวก ภาษาอังกฤษที่บรรยายใน webcast  ก็ฟังเข้าใจไม่ยากด้วย ท้ายๆ ของการบรรยาย มีตัวอย่างการใช้งาน BI ในทีมเบสบอลด้วย เช่นการตัดสินใจว่าจะเลือกหาผู้เล่นสำรองจากแหล่งไหน เป็นต้น น่าสนใจดีทีเดียว