BzInsight

Vuca ย่อมาจาก Volatility, uncertainty, complexity and ambiguity เดิมศัพท์คำนี้ใช้กันในวงการทหาร แต่เมื่อไม่นาน ก็เอามาใช้อธิบายลักษณะการสภาพแวดล้อมทางสังคมและเศรษฐกิจในปัจจุบัน slideshare ข้างล่างนี้อธิบายด้วยภาพไว้ได้น่าสนใจดี ถึงแม้หลายตัวอย่างจะอเมริกันจ๋าไปซักหน่อยก็เถอะ

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

• V = Volatility –> Vision
• U = Uncertainty –> Understanding
• C = Complexity –> Clarity
• A = Ambiguity –> Agility

ลักษณะการ 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% ก็ใช้ได้แล้ว เพราะในความจริง มีอยู่หลายกรณีเหมือนกันที่เราจำเป็นต้องมีข้อมูลที่ถูกต้องแม่นยำ ตัวอย่างเช่น

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

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

ในบริษัทขนาดใหญ่ กิจกรรมอย่างหนึ่งที่เสมอขึ้นบ่อยๆ เพื่อกระตุ้นการเติบโต คือการซื้อกิจการ (acquisition) หรือการควบรวมกิจการ (merger) เหตุผลทางธุรกิจก็มีมากมายหลากหลายกันไป แต่สิ่งหนึ่งที่มักจะตามมาเสมอ คือการผนวกรวมระบบ IT ของสององค์กรเข้าด้วยกัน ไล่ไปตั้งแต่ระบบพื้นฐาน อย่างเน็ตเวิร์ค โทรศัพท์ อีเมล์ ขึ้นไปจนถึงระบบที่รองรับกระบวนการทำงานพื้นฐาน อย่าง ERP, SCM, CRM  และแน่นอนระบบ Business Intelligence ทั้งหลาย เริ่มตั้งแต่รายงานยอดขายพื้นฐาน ไปจนถึงระบบที่ซับซ้อนอย่างจำพวก Dashboard หรือ BPM

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

The show must goes on
แน่นอนที่สุดว่า กิจการใดๆ จำเป็นที่จะต้องดำเนินธุรกิจต่อไปได้ในช่วงเวลาระหว่างการควบรวมกิจการ ไม่ใช่ประกาศวันนี้ พรุ่งนี้หยุดบริษัทไป 6 เดือนรอจนควบรวมกิจการเสร็จค่อยเปิดทำการต่อ คงได้เจ๊งกันเป็นแถว ดังนั้นประเด็นแรกสุดคือการดูแลให้ธุรกิจสามารถเดินต่อไปได้ จะว่าง่ายก็ง่าย แต่บางทีก็ลำบากเหมือนกัน เพราะหลายครั้งที่พอประกาศซื้อกิจการปุ๊บ ลดพนักงานทันที หรือไม่ก็พนักงานลาออกเอง จึงมีความเป็นไปได้มาก ที่คนที่ดูแลระบบ BI เดิมจะอยู่ในกลุ่มนั้นด้วย ต้องรีบเก็บเกี่ยวความรู้กับพวก document ต่างๆ เอาไว้ให้ได้มากที่สุด จะได้รู้ว่าระบบที่กำลังทำอยู่นั้น หมกอะไรไว้แค่ไหนบ้างหรือไม่

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

Seek first to understand
พอเริ่มตั้งหลักได้ สิ่งที่ควรทำอย่างยิ่งอย่างหนึ่งเลยคือการนั่งพูดคุยกับผู้บริหารทางฝั่งของธุรกิจ เพื่อทำความเข้าใจก่อนว่า กิจการหลังการควบรวมนั้น จะเดินหน้าต่อไปอย่างไร บริษัทจะรวมกันมั้ย (ทางกฎหมาย) หรือจะยังแยกเป็นสองหน่วยธุรกิจ ไลน์สินค้าจะมีการเปลี่ยนแปลงหรือไม่ โครงสร้างองค์กรจะเปลี่ยนไปอย่างไร ช่องทางการจัดจำหน่าย กลยุทธ์ทางการตลาดและการดูแลลูกค้าจะปรับเปลี่ยนไปแค่ไหน แนวทางเหล่านี้ส่วนใหญ่ผู้บริหารระดับสูงคิดเอาไว้แล้วแหละ เพียงแต่อาจจะไม่ได้ประกาศออกไปเป็นวงกว้างในองค์กร และโดยมากก็มักจะมีการวางแผนกันเป็นระยะเวลายาว 2-3-4 ปีจนกว่าการควบรวมจะสมบูรณ์ มีการแบ่งออกเป็นเฟสต่างๆ เพื่อให้การเปลี่ยนแปลงเป็นไปแบบค่อยเป็นค่อยไป ในระดับที่เจ้าหน้าที่ในองค์กรสามารถปรับตัวได้ทัน

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

การเข้าใจแผนงาน และแนวทางการดำเนินธุรกิจหลังการควบรวม จะทำให้เราสามารถวางแผนงานด้าน IT และด้าน BI ได้สอดคล้องกับแนวทางเหล่านั้นได้มากขึ้น และมีเวลาเตรียมความพร้อมของระบบเพื่อสนับสนุนเฟสต่างๆ ของการรวมกิจการ

Plan and execute
พอเข้าใจกรอบแนวทางของธุรกิจแล้ว ก็ย้อนกลับมาดูด้านระบบ BI บ้าง เอาแผนธุรกิจวางไว้เป็นกรอบ แล้วก็วางแผนย้อนหลังกลับมา ถ้าจะมีการปรับเปลี่ยนแนวทางการดำเนินธุรกิจในอีก 2 ปีข้างหน้า (หลังการควบรวม) ระบบ BI ที่จะสนับสนุนงานนั้น ต้องมีลักษณะอย่างไรบ้าง เราจะได้รูป future state คร่าวๆ แล้วก็มาพิจารณาเปรียบเทียบกับความสามารถในปัจจุบัน ของทั้งสองบริษัท ร่างรายการออกมาว่ามีอะไรจะต้องปรับเปลี่ยนบ้าง ส่วนไหนที่ซ้ำซ้อน ส่วนไหนที่เป็นปัญหาต้องแก้ไข อะไรที่ยังขาดอยู่และต้องพัฒนาเพิ่มเติม ร่างรายการเหล่านี้เสร็จ เราก็ได้ transition plan พอดี ขั้นต่อไปก็ไปหาเงินมาทำงานตามแผนงานนั้น (พูดเหมือนง่าย แต่ความจริงยากกว่าส่วนอื่นๆ อีก)

กระบวนการเหล่านี้ใช้เวลานะครับ หลายเดือน จนเป็นปี อย่าด่วนหักโหม แบบประเภทซื้อบริษัทใหม่เข้ามา โยน BI ของบริษัทใหม่ทิ้งไปให้หมด เอาระบบของเราไปให้เขาใช้ user อาจจะไฟธาตุแตกเอาได้ง่ายๆ แถมยังเสียโอกาสที่จะได้ปรับปรุงระบบของเราให้ดีขึ้นอีกด้วย

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.

หนึ่งในคำถามสำคัญของระบบ BI/DW คือ ข้อมูลจะทันสมัยแค่ไหน ถ้าผู้ใช้เปิดรายงานหรือเปิด cube เช้าวันจันทร์ จะเห็นข้อมูลของเมื่อวันศุกร์สัปดาห์ที่แล้ว เสาร์ที่ผ่านมา หรือข้อมูลล่าสุดเมื่อเย็นวันอาทิตย์ ความทันสมัยของข้อมูลหรือ timeliness นี้ เป็นหนึ่งในจุดขายของระบบ Business Intelligence ทั่วไปประเภทโฆษณาว่า เราสามารถให้ real-time data analysis หรือ up to the minute data ได้

ความจริงการโฆษณาอย่างนั้น ก็ไม่ได้ผิดพลาดอะไรหรอก เพียงแต่ว่า น่าจะมีการทำ remark เล็กๆ ไว้หน่อยว่า เงื่อนไขที่จะได้ข้อมูลทันสมัยขนาดนั้นน่ะ มีอะไรบ้าง

ปัจจัยหลักที่ส่งผลกระทบต่อความทันสมัยของข้อมูลในระบบ BI/DW ไม่ได้ขึ้นอยู่กับตัวระบบเอง แต่ขึ้นอยู่กับความพร้อมของแหล่งข้อมูลต้นทาง หรือ source system มากกว่า อย่างที่ทราบกันอยู่ว่า ข้อมูลที่ไหลเข้ามาในคลังข้อมูล มีต้นกำเนิดมาจากระบบอื่นๆ ไม่ว่าจะเป็น ERP, CRM หรือ SCM ยิ่งองค์กรมีขนาดใหญ่ ความหลากหลายของแหล่งข้อมูลก็ยิ่งมีมาก

ความหลากหลายของแหล่งข้อมูล ทั้งในแง่ของระบบ และขั้นตอนกระบวนการทำงาน ส่งผลต่อความสมบูรณ์หรือ completeness ของข้อมูลที่อยู่ในคลังข้อมูลในเวลาใดเวลาหนึ่ง ถ้าคุณมีระบบ data warehouse ที่ใช้รวบรวมข้อมูลยอดขายมาจากทุกสำนักงานขายทั่วโลก คุณจะ update ข้อมูลในคลังข้อมูลบ่อยแค่ไหน? ทันทีที่เริ่มประมวลผลข้อมูลที่เข้ามา ข้อมูลจาก source system ก็เปลี่ยนแปลงไปแล้ว ทันทีที่ตลาดทางเอเชียปิดทำการ ตลาดสหรัฐก็เริ่มทำงาน ดังนั้น ณ เวลาใดเวลาหนึ่ง ข้อมูลในคลังข้อมูล จะขาดความสมบูรณ์ไปเสมอ

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

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

ประเด็นหลักของการเลือกความถี่และช่วงเวลาในการประมวลผลข้อมูลใน data warehouse คือการหาจุดที่สมดุลกันระหว่าง timeliness กับ completeness โดยพิจารณาจากความต้องการของผู้ใช้เป็นหลัก และต้องเป็น need ด้วย ไม่ใช่แค่ wish โดยมากผมจะถามต่อว่า ผู้ใช้ใช้ข้อมูลไปทำอะไร (คงไม่มีใครแค่ต้องการ “ดู” ข้อมูลเฉยๆ เป็นแน่ เพราะข้อมูลน่ะไม่สวย และไม่สนุก ดังนั้นการเรียกใช้ข้อมูลแต่ละครั้งจึงมีเป้าหมายอยู่ในใจเสมอว่าจะทำอะไรกับข้อมูลเหล่านั้นบ้าง) และปรับความถี่ในการอัพเดตข้อมูลให้สอดคล้องกัน

ดูเอาขำๆ นะครับ อย่าคิดมาก เนื้อหาก็โฆษณาเราดีๆ นี่เอง แต่ทำได้น่ารักดี โดยเฉพาะเสียงคุณผู้หญิงนี่ แปร๋นได้ใจดีจริงๆ Merry Christmas ครับ