BzInsight

ลักษณะการ restatement แบบที่สองจะเป็นการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อมูลอ้างอิง (reference data หรือ master data) โดยเฉพาะ

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

ถึงแม้ว่าตัวข้อมูลธุรกรรมไม่มีการเปลี่ยนแปลง แต่การเปลี่ยนข้อมูลอ้างอิง ก็สามารถส่งผลให้ “เสมือน” ว่าข้อมูลในอดีตมีการเปลี่ยนแปลงไปได้เช่นกัน

• Hierarchy Change

Hierarchy หรือโครงสร้างลำดับขั้น เป็นหนึ่งในลักษณะที่สำคัญของข้อมูลอ้างอิง มีความสำคัญมากต่อการสรุปยอดข้อมูล หรือ aggregation โดยการกำหนดการจัดหมวดหมู่ของข้อมูลให้สอดคล้องกับ ความต้องการใช้งานในกลุ่มผู้ใช้แต่ละกลุ่ม ตัวอย่างเช่น ถ้าบริษัทของคุณมีลูกค้าซัก 1000 ราย และจัดแบ่งหมวดหมู่ตามโครงสร้างการบริหารของฝ่ายขาย ทีนี้สมมติบริษัทคุณแบ่งเขตการขายตามพื้นที่ที่อยู่ของลูกค้า คุณอาจจะมีผู้จัดการฝ่ายขาย 4 คน ประจำภาคเหนือ ใต้ กลาง และอีสาน แต่ละคนก็ดูแลลูกค้าที่มีที่อยู่อยู่ในภาคนั้นๆ ดังนั้น ระบบ business intelligence ที่ใช้รายงานยอดขาย ก็จะรวมยอดขายของลูกค้าแต่ละราย ตามเขตพื้นที่ที่ผู้จัดการฝ่ายขายแต่ละคนดูแลอยู่

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

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

ระบบ data warehouse หรือ business intelligence ที่ออกแบบมาเพื่อรองรับลักษณะการใช้งานเหล่านี้ จะมีการเก็บประวัติการเปลี่ยนแปลงของ hierarchy ไว้ (หรือถ้าเอาให้ง่ายกว่านั้นหน่อย ก็ใช้วิธีสร้าง hierarchy ใหม่ไปเสียเลย) อาจจะย้อนหลังไปซัก 2-3 เวอร์ชั่น เพื่อให้สามารถตอบสนองการวิเคราะห์ข้อมูลแบบพิเศษนี้ได้

• Attribute Change

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

ยอดขาย 100 ล้านบาทเท่ากัน อาจแสดงผลในรายงานแตกต่างกันในแต่ละปีได้ ถ้าใช้อัตราแลกเปลี่ยนที่แตกต่างกันของแต่ละปี

Reference data restatement ถือเป็นเรื่องปกติ และเป็นหนึ่งในข้อที่ควรพิจารณาเป็นอย่างยิ่งในการออกแบบคลังข้อมูลหรือระบบ business intelligence ใดๆ ข้อควรพิจารณาประกอบด้วย

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

โดยหลักการทั่วไปแล้ว ข้อมูลในคลังข้อมูลหรือ data warehouse จะมีลักษณะ non-volatile คือ ไม่มีการเปลี่ยนแปลงไปตามเวลา พอข้อมูลเข้าสู่คลังแล้ว มักจะอยู่ในรูปแบบอย่างนั้นไปตลอด แต่พอเอาเข้าจริง ก็มักจะพบกับความต้องการที่จะเปลี่ยนแปลงข้อมูลในคลังข้อมูลอยู่เสมอ เรียกกันว่า Data Restatement

Data Restatement ที่ผมประสบพบเจออยู่บ่อยๆ มีสองแบบ อย่างแรกเลยคือ transaction restatement ประเภทที่สองเรียกว่า reference data restatement ทั้งสองแบบนี้มีวัตถุประสงค์ที่แตกต่างกัน และต้องการการจัดการที่แตกต่างกันด้วย

Transaction Restatement

เป็นการเปลี่ยนแปลงข้อมูลธุรกรรมที่เกิดขึ้นในอดีต สมมติอย่างเช่น มีข้อมูลยอดขายสินค้า A ไปยังลูกค้า ก. ประจำวันที่ 1 ตุลาคม 52 ข้อมูลแรกสุดที่เข้ามาเก็บในคลังข้อมูลบันทึกได้ว่ายอดขายเป็น 100 บาท ตัวเลข 100 บาทนี้ได้ถูกนำไปเผยแพร่ หรือ publish รวมเข้ากับยอดขายสินค้าอื่นๆ ผู้บริหารอาจจะได้ทำการตัดสินใจอะไรบางอย่างไปเรียบร้อยแล้วเกี่ยวกับข้อมูลตัวนี้ (เช่น สั่งเพิ่มปริมาณการผลิตสินค้า A หรือ สั่งให้ส่วนลดพิเศษลูกค้า ก. ไปเรียบร้อยแล้ว) แต่แล้ว ภายหลังพบว่า ข้อมูลยอดขายที่แท้จริงเป็นแค่ 50 บาท จะเกิดอะไรขึ้น? และระบบคลังข้อมูลหรือระบบ business intelligence ควรจะตอบสนองกับกรณีเช่นนี้อย่างไร?

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

ดังนั้นแล้วกระบวนการ transaction restatement ต้องได้รับการอนุมัติเป็นกรณีพิเศษ จากผู้บริหารที่สามารถรับผิดชอบผลทางกฎหมายที่จะตามมาจากการแก้ไขข้อมูลได้

สิ่งที่เราพอจะช่วยได้ ก็คือการออกแบบโครงสร้างข้อมูลใน data warehouse ให้รัดกุม ครอบคุลมกระบวนการทางธุรกิจทั้งหลายทั้งปวง อันเป็นที่มาของการแก้ไข transaction ในอดีต รวมไปถึงการทำงานร่วมกับระบบงานอื่นๆ เช่น SCM หรือ ERP เพื่อสร้างระบบควบคุมที่เหมาะสมด้วยเช่นกัน ตัวอย่างเช่น ลงวิเคราะห์กันดูว่า เพราะสาเหตุใดที่ทำให้ยอดขายซึ่งเคยเป็น 100 บาท เปลี่ยนเป็นแค่ 50 บาทได้? เราอาจจะพบว่า เกิดจากพนักงานคีย์ราคาผิด (ควบคุมผ่าน ERP) หรือคีย์จำนวนสินค้าผิด (ควบคุมผ่านกระบวนการส่งของ) หรืออาจจะเกิดจากการที่สินค้าจัดส่งไปแล้ว แต่ลูกค้าคืนสินค้ากลับมาครึ่งหนึง (แก้ไขโดยการออกแบบฐานข้อมูลที่รองรับการคืนสินค้า) เป็นต้น

เอาไว้คราวหน้ามาคุยให้ฟังเรื่อง reference data restatement ต่อแล้วกันครับ

สัปดาห์ที่แล้วผมใช้เวลาทั้งสัปดาห์อยู่ในประเทศจีน ทำ mapping & matching session ให้กับระบบ logistics โดยเน้นไปที่สองเรื่องคือการจัดการสินค้าคงคลัง และการบริหารคำสั่งซื้อที่ไม่สามารถตอบสนองได้ (order cut) เพื่อเพิ่มความสามารถในการให้บริการแก่ลูกค้า เราเข้าไปพร้อมกับระบบที่พัฒนาขึ้นมาเรียบร้อยแล้ว และมีการนำไปใช้งานได้ผลดีมากในรัสเซีย และกำลังจะนำมาใช้ในจีนแผ่นดินใหญ่ เป้าหมายง่ายๆ ที่เราตั้งกันไว้ก็คือ ควรจะสามารถสร้างระบบ BI ที่บอกผู้บริหารได้ว่า สถานการณ์สินค้าคงคลังเป็นอย่างไรบ้าง ในแต่ละประเทศ ลึกลงไปจนถึงขั้น แต่ละคลังสินค้าในส่วนของตัวแทนจำหน่ายแต่ละราย รวมถึงความสามารถในการให้บริการของตัวแทนจำหน่ายด้วย ว่าสามารถให้บริการลูกค้าได้ดีเพียงใด โดยดูจากเปอร์เซ็นต์การขายที่สามารถจัดส่งสินค้าได้ เทียบกับคำสั่งซื้อรวมที่ลูกค้าสั่งมา ระบบดังกล่าวนี้ ควรจะสามารถนำไปใช้ได้กับประเทศต่างๆ ได้โดยไม่ต้องเปลี่ยนแปลงแก้ไขอะไรมากมายนัก

การสร้างระบบ BI ที่จะทำให้ผู้บริหารสามารถเห็นภาพรวมของธุรกิจได้หลายประเทศ (ที่มีระบบ OLTP แตกต่างกัน) สิ่งที่สำคัญที่สุดคือมาตรฐานของนิยามข้อมูล หรือ data definition standard ที่มีความจำเป็นจะต้องสอดคล้องกัน ไม่อย่างนั้น จะก่อให้เกิดปัญหาตามมามากมาย ผมยกตัวอย่างคำถามเกี่ยวกับนิยามของข้อมูลอย่างเช่น

ปริมาณสินค้าคงคลังที่ตัวแทนจำหน่าย (inventory หรือบางทีก็เรียก stock)

• เริ่มต้นนับจากเมื่อใดที่ตัวแทนจำหน่ายเป็น “เจ้าของ” สินค้านั้น ในบางพื้นที่ที่การขนส่งใช้เวลานาน การส่งสินค้าออกจากโรงงานต้นทาง ไปจนถึงคลังสินค้าของตัวแทนจำหน่ายอาจใช้เวลาถึง 5 วัน สมมติว่าส่งสินค้า 100 ลัง เจ้าสินค้า 100 ลังนี้ จะถูกนับว่าเป็น inventory ของบริษัท หรือเป็นของตัวแทนจำหน่าย ในช่วงเวลา 5 วันนี้?
• สินค้า “แถม” หรือสินค้าโปรโมชั่นที่มีการรวมเอาผลิตภัณฑ์อย่างอื่นไปด้วย ไม่ได้นับเป็นยอดขาย แต่จะนับรวมอยู่ในยอดสินค้าคงคลังด้วยหรือไม่?
• สินค้าเก่า, เสียหายเนื่องจากการขนส่ง, หรือกำลังจะหมดอายุ (นำไปขายต่อไม่ได้แล้ว) ถูกนับรวมอยู่ในยอดสินค้าคงคลังด้วยหรือไม่?
• การคำนวณมูลค่าของสินค้าคงคลัง ใช้วิธีใด ระหว่าง LIFO, FIFO หรือจะใช้ปริมาณคูณกับต้นทุนมาตรฐาน?
• การคำนวณ Days of Supply หรือ Days On Hand (ซึ่งเป็นตัวชี้วัดอย่างหนึ่งที่บอกว่า ถ้าไม่มีการสั่งสินค้ามาเพิ่มเติม ปริมาณสินค้าคงคลังที่มีอยู่ จะสามารถขายได้ประมาณกี่วัน) ใช้สูตรอะไรในการคำนวณ?

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

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

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

• กระบวนการทำงานที่อาจต้องปรับเปลี่ยน
• วิธีการบันทึกข้อมูล
• การประมวลผล, จัดเก็บข้อมูลใน OLTP, รวมถึงการ extract ข้อมูลออกมาด้วย
• การเปลี่ยน “ความเคยชิน” ในการใช้ข้อมูล ถ้านิยามของข้อมูลเปลี่ยนแปลงไป

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

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

ผมยังไม่เคยเห็น software ที่ใช้ “เลือก supplier” โดยเฉพาะนะครับ มีแต่ที่ใช้ในการช่วยจัดการบริหารความสัมพันธ์กับ supplier (supplier relationship management) ซึ่งมีลักษณะคล้ายๆ เป็น ERP ในระบบ ERP เองโดยทั่วไปก็มีส่วนนี้อยู่แล้ว โดยมักจะอยู่ในส่วนโปรแกรมจัดซื้อ

เมื่อวานนี้คุยเรื่องความแตกต่างระหว่าง business requirement กับ system requirement มาเช้านี้ไปเจอบทความนี้เข้า The Need to Simplify Data and Reporting ซึ่งก็สอดคล้องกับที่คิดไว้เหมือนกัน โดยเฉพาะอย่างยิ่ง ประเด็นที่ว่า 80% ก็ดีพอแล้ว ซึ่งอันนี้เห็นด้วยอย่างยิ่งเลย

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

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

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

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

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

• ข้อมูลเกี่ยวกับบัญชีที่มีความจำเป็นต้องถูกต้องตามที่กฎหมายกำหนด
• ข้อมูลที่เกี่ยวข้องกับธุรกรรมทางการเงิน
• ข้อมูลที่จะถือว่าเป็นหลักฐานอย่างเป็นทางการ

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

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

โดยปกติแล้ว การทำความเข้าใจความต้องการทางธุรกิจของระบบ BI ควรจะทำโดยผู้ใช้งานโดยตรง เพราะมีความจำเป็นจะต้องมีความรู้เกี่ยวกับขั้นตอนการทำงานและกระบวนการตัดสินใจ ตลอดจนข้อมูลที่จำเป็นต้องใช้ประกอบการตัดสินใจในแต่ละขั้นตอน แต่ตัวผู้ใช้เองก็มีหน้าที่ในงานที่ได้รับผิดชอบอยู่แล้ว การมีส่วนร่วมในการพัฒนาระบบ BI จึงมักจะกลายเป็นงาน part time อยู่เสมอ การรวบรวมและวิเคราะห business requirement เลยกลายเป็นหน้าที่ของนักวิเคราะห์ระบบไป

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

โดยส่วนตัวแล้ว ผมแบ่งประเภทของ requirement ออกเป็นสามแบบคร่าวๆ คือความต้องการทางธุรกิจ ความต้องการด้านข้อมูล และความต้องการทางด้านระบบ

Business Requirements

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

Data Requirements

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

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

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

System Requirements

ทั้ง business และ data requirements จะเป็นตัวกำหนดความต้องการทางเทคนิคของระบบ ว่าระบบงาน BI ที่เราต้องการนั้น จะมีลักษณะหรือความสามารถทางเทคนิคอย่างไรบ้าง เช่น เมื่อผู้ใช้เปลี่ยนขอบเขตหรือตัวเลือกของข้อมูลอ้างอิง ระบบจะต้องสามารถคำนวณข้อมูลให้ใหม่ได้ภายในเวลาไม่เกิน x วินาที เป็นต้น จะต้องสามารถโหลดข้อมูลใหม่ในแต่ละวันจำนวน 20 ล้านแถวได้ภายในเวลา x ชั่วโมง เป็นต้น

ปัญหาที่ผมพบบ่อยก็คือ นักวิเคราะห์ระบบบางคน หรือบางทีก็รวมไปถึงผู้ใช้เองด้วย ไม่ได้แยกประเภทความต้องการเหล่านี้ออกมา ก็เรียกรวมๆ กันเลยว่าเนี่ย business requirement ฉันต้องการรายงานหน้าตาอย่างนี้นะ update ทุกวัน แสดงข้อมูลย้อนหลังได้ 5 ปี ถ้ากดอย่างนี้ ได้ผลลัพธ์อย่างนี้ เรียกได้ว่า ทำทุกอย่างเหมามาหมด ออกมาเป็น system requirement เลย ยื่นให้โปรแกรมเมอร์ลงมือทำเลยทันที (โดยมากมักมาในรูปแบบของ report format หรือไม่ก็ system mockup) ทางด้านโปรแกรมเมอร์หรือ system owner บางทีก็บ้าจี้ตามไปด้วย รับอะไรมาก็ก้มหน้าก้มตาทำกันไป

ทีนี้ปัญหามันมาเกิดตรงที่ บางครั้งระบบหรือความต้องการอย่างใดอย่างหนึ่ง มันเป็นส่วนหนึ่งของแพลตฟอร์มหรือโครงการที่ใหญ่กว่านั้น แถมยิ่งพอเราใช้ data warehouse เป็นหลักในการเก็บข้อมูล การปรับเปลี่ยนแก้ไขโดยดูจาก system requirement อย่างเดียว บางทีก็ส่งผลกระทบแย่ๆ ต่อการพัฒนาคลังข้อมูลเหมือนกัน หรือไม่บางทีก็กลายเป็นการขี่ช้างจับตั๊กแตนกันไป

หลายปีมาแล้ว ผมเคยปฎิเสธ change request ฉบับหนึ่ง ที่ขอให้เปลี่ยนวิธี aggregate ข้อมูลในรายงานจาก simple average มาใช้วิธี weighted average (อันนี้ผมมองว่าเป็น data/system requirements) โดยทาง analyst อ้างว่า ผู้ใช้เกิดข้อสงสัยในตัวรายงาน ว่าข้อมูลอาจจะไม่แม่นยำเพียงพอ (business requirement) เธอเลยเสนอให้เปลี่ยนวิธีคำนวณ ผมคำนวณดูคร่าวๆ แล้วพบว่า มันไม่ได้ช่วยอะไรเท่าไหร่ แค่เพิ่มความแม่นยำของตัวเลขรายงาน จากทศนิยม 1 ตำแหน่ง ทำให้ถูกต้องมากขึ้นจนถึงตำแหน่งที่ 3 เท่านั้นเอง แต่ต้องยกเครื่อง aggregation engine ใหม่ แถมใช้เวลา process รายงานนานขึ้น 2 เท่า เลยกลับไปถาม business sponsor ง่ายๆ ว่า ถ้าตัวเลขในรายงานเปลี่ยนไปจาก 81.2% ไปเป็น 81.1882% จากทำให้คุณตัดสินใจแตกต่างไปจากเดิมหรือไป แล้วถ้าจะต้องลงทุนอีก $xxx เพื่อให้ได้รายงานที่ละเอียดขึ้น คุณจะยอมจ่ายหรือเปล่า

สุดท้ายเราแก้ปัญหา business requirement ที่ต้องการข้อมูลที่แม่นยำขึ้น โดยการปรับเปลี่ยนขั้นตอนการเก็บข้อมูลครับ ไปเปลี่ยนเอาที่ต้นทางตอนเกิด transaction ขึ้น โดยไม่ได้เปลี่ยนแปลงอะไรในระบบ reporting system เลย เพราะเมื่อเราพิจารณาแยกส่วนกันระหว่าง business requirement กับ data/system requirement ก็พบว่าทางแก้ปัญหาที่เหมาะสมกว่า มันอยู่นอกระบบ BI นั่นเอง

BusinessWeek เพิ่งลงบทความเรื่อง Business Intelligence Software’s Time Is Now โดยประเด็นหลักที่โปรยไว้ก็คือสภาพเศรษฐกิจถดถอยตอนนี้น่าจะช่วยกระตุ้นให้เกิดการเติบโตในการใช้ซอฟต์แวร์ BI มากยิ่งขึ้น

Still, about two-thirds of large U.S. companies believe they need to improve their analytical capabilities and only half believe they are spending enough on business analytics, according to an Accenture (ACN) survey of 250 executives that was released in December. In it, about 57% of companies said they don’t have a beneficial, consistently updated, companywide analytical capability, and 72% are working to increase their company’s use of business analytics. Today, only 60% of major decisions are based on analytics, according to the survey, while 40% are based on intuition.

ใกล้สิ้นปี 2008 มาดูกันดีกว่าว่าปีหน้า 2009 แนวทางของ BI จะเป็นยังไง ผมเอาคำทำนายพวกนี้มาจาก What’s in store for Business Intelligence in 2009

• Cloud computing will cause a shift in the BI balance of power from IT to business users
• Simplicity will be the driving mantra for both consumers and vendors of BI
• The continued drive for simplicity will cause a shift towards prebuilt analytic solutions with best practices built in, and away from generic toolsets
• Data interpretation will become a significant challenge for new BI users

ผมเห็นด้วยที่สุดเห็นจะเป็นข้อสองเรื่องของ simplicity แถมอีกอย่างด้วยคือ agility คือความเร็วและง่ายในการเพิ่มข้อมูล หรือรูปแบบการวิเคราะห์ใหม่ๆ ได้คุยกับ financial analysts เขาบ่นให้ฟังว่า สถานการณ์เศรษฐกิจเปลี่ยนแปลงไปรวดเร็วมาก ราคาน้ำมัน ราคาวัตถุดิบ อัตราแลกเปลี่ยน swing ไปมาเป็นช่วงกว้าง forcast ยากสุดๆ ความต้องการใหม่ๆ ด้านข้อมูลและการวิเคราะห์ผุดมาเรื่อย การทำระบบ BI แบบเดิมๆ ที่ต้องใช้เวลานานๆ ไม่ได้ผลอีกแล้ว ผู้ใช้ต้องการอะไรที่ง่ายๆ และเปลี่ยนได้เร็วๆ แต่ในขณะเดียวก็ยังคง maintain integrity ของข้อมูลไว้ด้วย

ส่วนเรื่อง pre-built analytics ผมยังไม่เห็นชัดมากนัก แต่ไม่คิดว่าจะเ็ป็นกระแสหลักมากนักในระดับ enterprise ถ้ามองในระดับ departmental อาจจะเป็นไปได้ที่มีการเลือกใช้ pre-buit analytics มากกว่า generic tool แต่ผมยังมองไม่ออกว่า เครื่องมือแบบบ pre-built ของ vendor รายใดรายหนึ่งจะเหมาะกับองค์กรใดองค์กรหนึ่งไปเสียทุกส่วน อย่าลืมนะครับว่า งาน enterprise ให้ความสำคัญกับเรื่อง integration มากเป็นพิเศษ ถ้าจะเืลือก pre-built ที่เหมาะกับงานส่วนใดส่วนหนึ่ง ก็อาจจะไม่เหมาะกับส่วนอีื่นก็ได้ สุดท้ายถ้าไม่เจอปัญหา integration ก็ไม่พ้นลงเลยที่ generic tool อยู่ดี

เรื่อง cloud คงไม่คอมเม้น เพราะยังไม่เห็นการใช้งานจริงๆ กับตาตัวเอง ส่วนข้อสุดท้ายเรื่อง data intepretation ผมมองว่ามันเป็น given อยุ่แล้ว ไม่ใช่เรื่องใหม่แต่อย่างใด

ใครที่สนใจข่าวคราวความเคลื่อนไหวเกี่ยวกับ BI และใช้ Twitter เหมือนผม คงสนใจรายชื่อ BI Industry twitter user (เป็น Google spreadsheet)

รายชื่อนี้รวบรวมโดย Shown Rogers (@shawnrog) ที่มา

ใครทราบแหล่งข้อมูลเกี่ยวกับ BI เป็นภาษาไทย ก็รบกวนแปะไว้ใน comment ด้วยนะครับ ถ้าใครสนใจ หรือทำงานด้านเดียวกัน และใช้ twitter ก็บอกด้วย (@p_warawit)  เราอาจมีมี BI twitter list ภาษาไทยบ้างก็ได้

ระหว่างมองหาผู้ให้บริการด้าน business intelligence ก็ผ่านไปเจอเข้ากับบริษัท yellowfin ซึ่งมี url เป็น http://www.yellowfin.bi ที่น่าสนใจก็คือ เขาใช้โดเมน .bi ซึ่งในที่นี่หมายถึง business intelligence ความจริงก็เคยได้ยินมาเมื่อเร็วๆ นี้ ที่มีการเปิดให้จดทะเบียน top-level domain name อื่นๆ นอกเหนือจาก .com .net .org และอื่นๆ ที่คุ้นเคยกันทั่วไป

เห็นอย่างนี้ผมก็นึกว่า ดีเลย ต่อไปคงมีเว็บไซต์เกี่ยวกับ Business Intelligence ที่เป็น .bi ขึ้นมาอีกเยอะแยะ น่าจะไปจองไว้บ้างเหมือนกัน แต่พอค้นไปค้นมา ปรากฎว่า .bi นี่มีเจ้าของอยู่แล้วนะครับ เป็นของประเทศ Burundi http://en.wikipedia.org/wiki/Burundi ซึ่งผมเองก็ไม่ทราบเหมือนกันว่าออกเสียงว่าอย่างไร อยู่ในทวีปแอฟริกา

ถึงแม้ว่า .bi http://en.wikipedia.org/wiki/.bi จะดูแลโดยหน่วยงานของประเทศ Burandi เอง แต่ก็เปิดให้มีการจดทะเบียนโดยใครก็ได้ เพียงแต่ขออย่าให้เป็นการนำไปใช้เพื่อให้เข้าใจผิด จะว่าไปแล้ว ก็ดูน่าเห็นใจอยู่เหมือนกัน เพราะคงไม่มีใครอยากให้ตัวย่อประเทศของตัวเอง มีความหมายกลายเป็นอย่างอื่น