ก่อนเริ่มลงมือทำโครงการ Business Intelligence ใดๆ ก็ตาม สิ่งที่ผมมักจะทำเสมอคือการ “ประเมิน” ความพร้อมของข้อมูลอ้างอิง หรือ master data readiness ที่มีอยู่ภายในองค์กร หรือภายในแหล่งข้อมูลเบื้องต้นก่อนเสมอ ไม่ว่าจะเป็นโปรเจ็คที่ดูเหมือนจะง่ายๆ อย่างเช่น reporting system หรือจะเป็นลักษณะที่ซับซ้อนมากขึ้นอย่างการผสานรวมข้อมูลจากหลายๆ แผนกเข้าด้วยกัน หนึ่งในหัวข้อหลักที่ผมมักจะถามอยู่เสมอคือ ข้อมูลอ้างอิงมีความพร้อมแค่ไหน และจะต้องทำอะไรบ้าง เพื่อให้มีความพร้อมเพียงพอ
สิ่งที่จะต้องรู้ก่อนก็คือ BI solution หรือระบบที่กำลังจะพัฒนา หรือกำลังจะนำมาใช้ มีความต้องการข้อมูลอ้างอิงอะไรบ้าง และอย่างไรบ้าง ผมเรียกส่วนนี้ว่า master data requirements แต่ละระบบงานก็มีความต้องการแตกต่างกันออกไป คนที่น่าจะรู้เรื่องความต้องการเหล่านี้ได้ดีที่สุดคือ คนที่เป็นเจ้าของ solution
พอเข้าใจแล้วว่าต้องใช้ข้อมูลอ้างอิงอะไรบ้าง คราวนี้ก็มาถึงคราวสำรวจตรวจความพร้อมกัน วัตถุประสงค์การสำรวจคือ
เพื่อให้ทราบถึงสิ่งที่ต้องทำในระหว่างการทำโครงการ เพื่อให้ได้ข้อมูลอ้างอิงที่ครบถ้วนและถูกต้องเพียงพอต่อการใช้งาน
โดยทั่วไปแล้วปัญหาของคุณภาพข้อมูลอ้างอิงในระบบงานไอที เพียงแต่ปัญหาเหล่านั้นอาจจะไม่ได้ส่งผลกระทบรุนแรงในแง่ของการปฎิบัติการ หรือมิฉะนั้นก็อาจจะไม่สามารถมองเห็นได้ชัดเจนถึงความรุนแรงของปัญหา แต่การนำระบบ BI มาใช้ จะเป็นการเปิดเผยปมปัญหาคุณภาพของข้อมูลที่ไม่มีใครเคยเห็นมาก่อนก็ได้
ผมมักจะตั้งต้นด้วยคำถามง่ายๆ เหล่านี้ ในแต่ละชนิดของข้อมูลอ้างอิง
- อธิบาย “ความหมาย” ของข้อมูลอ้างอิง ทั้งทางด้านความเข้าใจทางธุรกิจ และทางด้านการใช้งานในระบบ IT
- ตัวอย่างเช่น “สินค้า” มีความหมายรวมถึงสินค้าที่เป็นของแจกแถมด้วยหรือไม่ สินค้าเก่าหยุดจำหน่ายนานแค่ไหน ถึงจะถูกพิจารณาว่า ไม่ต้องการให้ปรากฎในรายงานการขายอีกต่อไป ในระบบคอมพิวเตอร์ที่ใช้อยู่ มีการบันทึก “สินค้าลวง” (dummy) ไว้บ้างหรือเปล่า? อาจจะเพื่อความสะดวกในการปรับยอดทางบัญชี
- อธิบาย “กระบวนการจัดการ” ข้อมูลอ้างอิง ไม่ว่าจะเป็นการสร้างเพิ่ม การเปลี่ยนแปลง หรือการลบข้อมูลอ้างอิง
- ตัวอย่างเช่นข้อมูล “ลูกค้า” ใครเป็นคนอนุมัติให้สร้างลูกค้ารายใหม่ขึ้นได้ในระบบ ใครเป็นคนบันทึกลงในฐานข้อมูล ถ้าลูกค้าขอการเปลี่ยนแปลงที่อยู่ในการจัดส่งสินค้า ใครจะเป็นคนแจ้งให้ฝ่ายบันทึกข้อมูลทราบ หรือถ้ามีการเปลี่ยนแปลงพนักงานขายที่ดูแลลูกค้ารายนี้ พนักงานบันทึกข้อมูลจะทราบได้อย่างไร
- ประมาณการปริมาณข้อมูลที่ “สอดคล้องกับความต้องการ” ของระบบ
- ตัวอย่างเช่น หากต้องการทำรายงานยอดขายรายจังหวัดและรายอำเภอของบริษัทที่มีลูกค้า 20,000 ราย ในบรรดาลูกค้าทั้งสองหมื่นรายนั้น มีจำนวนมากน้อยเท่าไหร่ที่มีข้อมูลจังหวัดและอำเภอบันทึกอยู่ในฐานข้อมูล เป็นไปได้มากทีเดียวที่จะมีลูกค้าเป็นจำนวนมาก ที่มีแต่ข้อมูลจังหวัด แต่ไม่รู้ว่าอยู่ในอำเภออะไร
- ประมาณการปริมาณข้อมูลที่ “ถูกต้องเที่ยงตรง” ตามที่ต้องการ
- ตัวอย่างเดิม ในบรรดาลูกค้า 20,000 รายที่มีอยู่ในระบบ อาจจะมีแค่ 50% หรือแค่ 10,000 รายเท่านั้นที่มีข้อมูลทั้งอำเภอและจังหวัด แต่กระนั้น ในบรรดา 10,000 รายที่มีข้อมูลจังหวัด อาจจะไม่ได้ถูกต้องเที่ยงตรงอย่างที่ต้องการก็เป็นได้ อาทิเช่น ความแตกต่างระหว่าง กรุงเทพฯ กับ กทม. หรือโคราชกับนครราชสีมา นี่ยังไม่นับโอกาสที่จะพิมพ์ผิดตกเกินอีกมากมาย ข้อมูลอ้างอิงของลูกค้า 20,000 ที่อยู่ในสภาพดีพร้อมใช้งานได้เลยอาจจะเหลืออยู่แค่ไม่ถึง 5,000 รายก็เป็นได้
การทำความเข้าใจกับสถานการณ์ปัจจุบัน จะช่วยให้การวางแผนการพัฒนาและติดตั้งระบบ Business Intelligence เป็นไปได้อย่างราบรื่นมากขึ้น อย่างน้อยก็ทำให้เห็นภาพได้ว่า มีความท้าทายอะไรรออยู่เบื้องหน้าบ้าง
ใน ระหว่างการเตรียมจัดงานประชุมประจำปีภายในของ IT manager ทั่วเอเชีย ผมเตรียมรายชื่อผู้เข้าร่วมงาน ซึ่งเป็น IT manager ระดับ section manager ขึ้นไปที่มี base location อยู่ใน Asia แล้วก็พบปัญหาหลายประการ ตัวอย่างเช่น
-
มีแหล่งข้อมูลมากกว่า 1 แห่ง
และ ที่สำัคัญ ไม่มีแหล่งไหนเลยที่มีทั้งครบถ้วนและถูกต้อง ผมมีรายชื่อมาจาก 3 แหล่งใหญ่ๆ ส่วนแรกคือ SAP-HR ซึ่งมีฐานข้อมูลไว้สำหรับจ่ายเงินเดือนพนักงาน แหล่งที่สองคือ LDAP ซึ่งมี web ให้สามารถดึงข้อมูลมาได้ เป็นข้อมูล account สำหรับเข้าสู่ระบบต่างๆ และสุดท้ายคือ รายชื่อของผู้เข้าร่วมประชุมเมื่อปีที่แล้ว
-
ข้อมูลย่อยที่กระจัดกระจาย
นอก จากราื่ยชื่อ เรายังต้องการข้อมูลประกอบด้วย อาทิเช่น ชื่อใน passport อีเมล์ เพศ ประเทศที่เป็น base location เชื้อชาติหรือประเทศต้นทาง รวมถึงหน่วยงานที่สังกัด ระดับหรือ band ผมพบว่าจากแต่ละแหล่งข้อมูลที่กล่าวมาข้างต้น ไม่มีแหล่งใดเลยที่มีข้อมูลทุกอย่างครบถ้วน SAP HR มีชื่อใน Passport แต่ไม่เก็บอีเมล์ มี base location (โดยดูจากประเทศที่จ่ายเงินเดือน) แต่ไม่มีเชื้อชาติ ส่วน LDAP มีอีเมล์เป็นหลัก กับหน่วยงานที่สังกัด น่าตลกที่ข้อมูลว่าใครเพศอะไร ต้องหาจากรายชื่อผู้เข้าร่วมประชุมปีที่แล้ว
ในแต่ ละแหล่งข้อมูล ผมพบว่ามีข้อมูลจำนวนหนึ่งซึ่งไม่อัพเดตเสมอ มีการย้ายแผนก (จาก IT ไปเป็น Sales หรือจากแผนกวิจัยตลาดมาทำงาน IT ก็มี) มีการย้ายหน่วยงานเช่น Expat มาจากยุโรปหรืออเมริกา แต่มาประจำในเอเชีย หรือไม่ก็ย้ายกลับ บางส่วนก็ลาออกไปบ้าง และที่เพิ่งถูกโปรโมทขึ้นมาเป็น IT manger ใหม่่ก็มีหลายคน บางทีตัวย้ายกลับไปยุโรปแล้ว แต่เงินเดือนยังรับเป็นของสิงคโปร์อยู่เลย หรือบางคนลาออกไปแล้ว แต่ยังอยู่ใน Payroll เพราะใช้วันหยุดพักร้อน กว่าจะ effective จริงๆ ก็อีก 2 เดือนข้างหน้า
ที่ น่าปวดหัวที่สุดคือ ข้อมูลจำเพาะที่มักจะรู้กันโดยไม่ได้บันทึกไว้ในฐานข้อมูล ในการรวบรวมรายชื่อผู้เข้าร่วมงานครั้งนี้ ผมต้องแยกข้อมูลชื่อจริง อีเมล์ และชื่อที่เป็นที่รู้จักกันทั่วไป (aka - as known as) ออกเป็น 3 ส่วน เพราะมันไม่ตรงกัน และสร้างความปวดหัวให้มาก คนที่เรารู้จักอาจจะมีอีเมล์หรือชื่อจริงแตกต่างไปจนจำไม่ได้ อาทิ
- คนญี่ีปุ่นเรามักจะเรียกด้วยนามสกุลเสมอ และบางทีก็เดาไม่ได้ด้วยว่าโคทาโร่ซังที่เราเรียกๆ กันอยู่นี่เป็นผู้หญิงหรือผู้ชาย
- คนจีนทุกคนจะตั้งชื่ออังกฤษของตัวเอง ซึ่งแทบไม่มีส่วนเกี่ยวข้องอะไรเลยกับชื่อจริง แถมนามสกุลออกเสียงคล้ายกันแต่สะกดต่างกันมาก
- ชาว อินเดียเป็นจำนวนมาก มีนามสกุลว่า singh เพื่อนผมคนหนึ่งมี อีเมล์เป็น singh.s.14 หมายความว่าเขาเป็นคนที่นามสกุล singh ชื่อต้นขึ้นด้วย s และมีคนลักษณะอย่างนี้มาก่อนหน้านี้แล้ว 13 คน
- ชาวเกาหลีกับชาวฟิลิปปินส์ มักใช้ชื่อย่อ ซึ่งอาจจะเป็น initials หรือพยางค์ใดพยางค์หนึ่งของชื่อ
- ชาวไทยก็เรียกกันด้วยชื่อเล่นเป็นหลัก เพราะทั้งชื่อจริง นามสกุลจริง ยาวพอๆ กัน ตัดปัญหาเลยบอกชาวบ้านให้เรียกเราในชื่อเล่น
จากปัญหาหลายอย่างที่กล่าวมา วิธีการที่ practical ที่สุดก็คือดึงรายชื่อจากแต่ละแหล่ง แล้วก็มารวมกันเอาโดยอาศัย personal knowledge โชคดีหน่อยที่รายชื่อคนมีไม่มากนัก แค่ไม่เกิน 100 คน แต่จำเป็นต้องใช้ network ของแต่ละองค์กร คือ IM ไปถามจากคนที่เรารู้จัก “รู้มั้ยคนนี้คือใคร?” หรือ “คนนี้ได้ข่าวว่าลาออกไปแล้ว จริงหรือเปล่า” แล้วก็มา cross reference ในแต่ละระบบด้วยตัวเองอีกที แถมงานแบบนี้จะให้น้องๆ admin ทำก็จะใช้เวลาเยอะไปหน่อย เพราะไม่ได้คลุกคลีทำงานด้วยกันกับ IT manager อื่นๆ แถมยังมีความเสี่ยงเรื่องการรักษาความลับด้วย โดยเฉพาะข้อมูลการโยกย้ายหรือปรับตำแหน่งของแต่ละคน
ปรากฎว่าผมใช้เวลาไปประมาณ 3-4 ชม. ในการรวบรวมและจัดการรายชื่อของคนแค่ 100 คน ซึ่งน่าจะใช้เวลาจริงๆ แค่ 3-4 นาที ถ้าเรามีระบบ master data management ที่มีประสิทธิภาพมากกว่านี้
ตัวอย่างนี้อาจจะพอทำให้เห็นภาพได้บ้างว่าปัญหาคุณภาพของข้อมูลอ้างอิง ส่งผลอย่างไรต่อประสิทธิภาพการทำงานในบริษัท ลองนึกภาพดูบ้างว่า แทนที่จะเป็นรายชื่อพนักงาน ถ้าเป็นรายชื่อลูกค้าที่เราต้องติดต่อด้วยเป็นประจำ และมีปริมาณมากกว่านี้ การตัดสินใจลงทุนทางด้าน MDM (ไม่เฉพาะแค่ระบบ แต่รวมไปถึงขั้นตอนกระบวนการในการควบคุมคุณภาพข้อมูลด้วย) น่าจะเป็นทางเลือกหนึ่งที่เพิ่มศักยภาพทางการแข่งขันได้มาก
ห่าง หายไปนาน เดี๋ยวจะคิดว่า series Master Data Management จบไปเสียแล้ว ยังครับ ยังไม่ได้เริ่มเลยด้วยซ้ำ แต่ก่อนจะเริ่มพูดถึง MDM ระดับทั่วทั้งองค์กร ลองมามองถึงปัญหาที่เกิดขึ้น เนื่องจากคุณภาพของข้อมูลอ้างอิงกันก่อน เริ่มกันที่ระบบงานคอมพิวเตอร์เพียงระบบเดียวนี่แหละ เพื่อให้เห็นภาพชัดเจนขึ้น ผมยกตัวอย่างว่า เรากำลังจะออกแบบและพัฒนาระบบลูกค้าสัมพันธ์ของร้านเช่าวีดีโอ (หรือน่าจะเป็น VCD/DVD แล้วสมัยนี้) แห่งหนึ่งในต่างจังหวัด ถ้าจะเรียกให้หรูหน่อยอาจจะเป็น CRM (Customer Relationship Management) ย่อยๆ ก็คงพอได้ ประมาณว่าเจ้าของกิจการรุ่นลูก เพิ่งจบ MBA มาหมาดๆ อยากทำแคมเปญการตลาดกระตุ้นยอดเช่าของลูกค้ารายเดิมๆ ก็อยากได้ระบบไอทีที่เก็บข้อมูลการติดต่อกับลูกค้าแต่ละรายไว้ อาทิเช่น ชื่อที่อยู่หมายเลขโทรศัพท์ รายการหนังที่เคยเช่าไป หรือรายการหนังค้างส่ง เป็นต้น เพื่อจะปรับกิจกรรมทางการตลาดได้
คราว นี้ลองสมมติว่า ถ้าข้อมูลอ้างอิงเกี่ยวกับลูกค้า (เอาแค่ลูกค้าอย่างเดียวก่อน) เกิดมีคุณภาพต่ำ อาทิเช่น ลูกค้าคนเดียว แต่เกิดมีรหัสลูกค้าสองหมายเลข หรือชื่อนามสกุล สะกดผิด ที่อยู่ หมายเลขโทรศัพท์ผิดพลาด เป็นต้น จะเกิดผลเสียอย่างไรบ้าง อย่างแรกเลยคือ ลูกค้าเสียความรู้สึก ถ้า คุณได้รับจดหมาย ที่ส่งมาถึงคุณ แต่สะกดชื่อหรือนามสกุลผิด หรือได้รับจดหมายเรื่องเดียวกัน จากบริษัทเดียวกัน ส่งมา 3-4 ฉบับ แน่นอนว่าคุณคงไม่ประทับใจเป็นแน่ แล้วแถมถ้าพวกแคมเปญการตลาดทั้งหลายที่พยายามจะทำ เกิดได้ข้อมูลผิดๆ มา จะยิ่งส่งผลเสียต่อความรู้สึกของลูกค้าเข้าไปใหญ่ (ไม่เคยเช่าหนังเรื่องนี้นี่นา ทำไมส่งจดหมายหรือโทรมาทวงหนังค้างส่งอยู่ได้ หรือ ในชีวิตนี้ไม่เคยชอบดูหนังผีเลย แต่กลับได้คูปองเช่าเขย่าขวัญ 2 แถม สยองขวัญ 1 มาได้ยังไงเนี่ย) พวกเมล์ขยะที่เราๆ รังเกียจกัน ก็เกิดจากการพยายามทำ CRM โดยไม่มีข้อมูลที่ดีพอนั่นเอง
ประการที่สอง ซึ่งก็ดูเหมือนจะต่อเนื่องมาจากประการแรกก็คือ ค่าใช้จ่ายที่เพิ่มมากขึ้น ไม่ ว่าจะเป็นค่าพิมพ์จดหมาย ค่าส่ง ค่าโทรศัพท์ สำหรับลูกค้าที่ส่งไปแล้ว เขาไม่มีโอกาสได้รับ เพราะที่อยู่หรือหมายเลขโทรศัพท์ไม่ถูกต้อง แถมดูเหมือนการลงทุนทั้งหลายทั้งปวงในระบบไอทีสุดหรูเพื่อทำ CRM ก็ดูจะเหมือนเป็นการตำน้ำพริกละลายแม่น้ำ เพราะอัตราการตอบรับ หรือยอดขายที่จะคาดว่าจะเพิ่มขึ้น ก็ไม่คุ้มกับต้นทุนที่ลงไป
ผมมองว่าปัญหาเกี่ยวกับคุณภาพของข้อมูลอ้างอิง แบ่งได้เป็นสามส่วน และมีความเกี่ยวโยงกัน ดังนี้
1. ขาดการกำหนดมาตรฐานและนิยามข้อมูลอ้างอิงที่ชัดเจน
อัน นี้เป็นข้อแรกที่เห็นบ่อยที่สุด โดยเฉพาะอย่างยิ่ง กิจการขนาดเล็กหรือระบบงานขนาดเล็ก ที่อาจจะมองข้ามความสำคัญของมาตรฐานข้อมูลไป การถามคำถามเหล่านี้ในระหว่างการรวบรวม requirement หรือการวิเคราะห์ระบบ อาจจะช่วยให้ผู้ใช้ระบบให้ความสำคัญกับมาตรฐานข้อมูลได้ (จากตัวอย่าง)
- รหัสหรือหมายเลขลูกค้าหนึ่งรายการ แทนอะไรในโลกแห่งความเป็นจริง บุคคลหนึ่งคน หรือหนึ่งครอบครัว
- แล้วถ้าจะมีนิติบุคคลมาสมัครเป็นลูกค้าเพื่อเช่าหนัง จะได้ไหม ?
- จะใช้ข้อมูลใดเป็นดัชนีแยกความแตกต่างของลูกค้าแต่ละราย ? ชื่อ หมายเลขประจำตัวประชาชน หมายเลขโทรศัพท์ เลขที่บ้าน ?
- แล้วถ้าลูกค้าเกิดเปลี่ยนชื่อละ จะถือเป็นลูกค้าอีกรายหนึ่งเลยหรือไม่ ?
- จะจัดแบ่งลูกค้าเป็นกลุ่มหรือเป็นหมวดหมู่อย่างไร แบ่งเพื่ออะไร ใช้เกณฑ์อะไรในการแบ่ง เพศ อายุ การศึกษา รูปแบบการดูหนัง
- รหัส ลูกค้า กำหนดอย่างไร เป็นตัวเลข หรือตัวอักษร (ภาษาไทยหรือภาษาอังกฤษ) มีจำนวนกี่หลัก เป็น intelligent code หรือเป็นแค่ running number ?
2. ขาดการกำหนดกฎเกณฑ์ทางธุรกิจในการจัดการกับข้อมูลอ้างอิง
กฎเกณฑ์ ทางธุรกิจ หรือ business rules จะเป็นอีกระดับขั้นหนึ่ง ซึ่งหลายๆ ระบบละเลยที่จะให้ความสำคัญ ต่อให้มีการกำหนดมาตรฐานและนิยามของข้อมูลอ้างอิงเอาไว้แล้ว แต่หากไม่ได้กำหนดกฎเกณฑ์ในการเข้าถึง เพิ่ม ลบ หรือแก้ไขข้อมูลอ้างอิง เอาไว้ให้รัดกุม ก็อาจส่งผลให้เกิดความเสียหายได้ ตัวอย่างเช่น
- หาก ธนาคารไม่กำหนดกฎให้ต้องใช้บัตรประจำตัวประชาชนเป็นหลักฐานในการเปิดบัญชี ธนาคาร ก็อาจเป็นช่องทางในการสร้างบัญชีปลอม และใช้ในการฟอกเงินได้
- หาก กิจการขายสินค้า ไม่กำหนดหลักเกณฑ์ในการอนุมัติเครดิต หรือวงเงินเครดิตที่แตกต่างกันไปตามประวัติการชำระเงินของลูกค้า ก็มีความเสี่ยงเพิ่มมากขึ้นด้านหนี้สูญ
3. ล้มเหลวในการนำมาตรฐาน นิยาม และกฎธุรกิจมาบังคับใช้ในระบบงานคอมพิวเตอร์
ต่อ ให้มีการกำหนดมาตรฐานและนิยามข้อมูล ตลอดจนกฎเกณฑ์ทางธุรกิจไว้แล้ว แต่หากไม่นำข้อกำหนดเหล่านั้นมา “บังคับใช้” ให้ผสานรวมเป็นส่วนหนึ่งในระบบงานคอมพิวเตอร์แล้ว ก็ย่อมเกิดความผิดพลาดเนื่องจาก human error ได้เสมอ ไม่ว่าจะด้วยความตั้งใจหรือไม่ก็ตาม ระบบงานคอมพิวเตอร์ที่ดี จึงควรนำข้อกำหนดที่ได้ระบุไว้ข้างต้น มาใส่ไว้เป็นส่วนหนึ่งของข้อกำหนดในการออกแบบระบบด้วย ไม่ว่าจะเป็นการตรวจสอบความสอดคล้องของข้อมูลด้วย referential integrity หรือ foreign key check การใช้ database trigger และ/หรือ cascade update-delete เพื่อบังคับใช้กฏทางธุรกิจให้เหมาะสม
ถ้า เราสามารถที่จะหลีกเลี่ยงปัญหาทั้งสามข้อนี้ไปได้ เราก็จะได้ระบบงานคอมพิวเตอร์ที่มีคุณภาพของข้อมูลอ้างอิงในระดับที่ดี ส่งผลให้ระบบสามารถตอบสนองความต้องการทางธุรกิจที่ได้วางไว้ได้
ได้อ่านบทความเรื่อง BI from a student perspective แล้ว ผมก็หันมานั่งทบทวนความรู้สึกของตัวเองเมื่อ 13-14 ปีที่แล้วครั้งสมัยที่เรียนป.โทด้าน MIS และเริ่มสนใจงานด้าน decision support system กับ data warehouse ใหม่ๆ ผมถูกดึงดูดด้วยศักยภาพของงานด้านนี้ที่จะสามารถทำ data mining ค้นหาโอกาสทางธุรกิจใหม่ๆ การวิเคราะห์ข้อมูลชั้นสูงที่จะเปิดตลาดใหม่ เพิ่มยอดขาย ลดต้นทุน และอื่นๆ อีกมาก
ผมฝันถึงการนำระบบ IT เข้ามาใช้ในองค์กร แล้วเพิ่มผลผลิตอย่างก้าวกระโดด ทุกคนในองค์กร ทุกระดับ สามารถตัดสินใจได้อย่างรวดเร็ว มีข้อมูลสนับสนุนทุกๆ การตัดสินใจ การวิเคราะห์ข้อมูลแบบใหม่ๆ เกิดขึ้น ส่งผลให้เกิดธุรกิจใหม่ตามมา สารพัดจะฝันแหละครับ ถ้าอ่านโบรชัวร์ของระบบ BI/DW สมัยนี้แล้ว “อิน” ตามคำโฆษณา ก็จะเข้าใจความรู้สึกของผมได้ไม่ยาก
แต่มาจนถึงวันนี้ หลังจากเวลาผ่านไป 10 กว่าปี ผมประเมินว่า ขีดความสามารถในการนำเอา BI มาใช้ในธุรกิจ ยังอยู่ในระดับที่ผิวเผินมาก หน่วยงานต่างๆ ไม่ได้ใช้สารสนเทศในการตัิดสินใจมากเท่าที่ควร สิ่งที่ผมสรุปได้กับตัวเองก็คือ การนำ BI มาใช้ในธุรกิจ ในโลกแห่งความเป็นจริง มันยากกว่าที่เราเคยเรียนมาหลายขุม ไม่ใช่แค่ เอาละ สร้าง database ขึ้นมาตัวหนึ่ง โหลดข้อมูลจาก transaction system ต่างๆ ลงไป เลือก BI tool หรือ reporting tool เข้าซักตัว install ให้ผู้ใช้ ตูม จบ ทุกคนได้รายงานตรงเวลา ทำวิเคราะห์กันสนุกสนาน ไม่เลยครับ มันไม่เคยง่ายอย่างนั้นเลย
อะไรทำให้ “ยาก” ?
ผมประเมินคร่าวๆ จากประสบการณ์ส่วนตัว พอจะจัดกลุ่มความท้าทายได้ดังนี้
- Data Quality Issue : ปัญหาโลกแตกของงาน BI เลยละครับ คุณภาพของข้อมูล อะไรที่เคยหมกๆ เอาไว้ตอนทำระบบงานต่างๆ พอนำ BI เข้ามาใช้ ปัญหาที่เกี่ยวข้องกับข้อมูลห่วยๆ จะผุดขึ้นมาเป็นดอกเห็ด
- Fighting the legacy : การนำระบบ BI เข้าไปใช้ทดแทน legacy system หรือระบบงานแบบเดิมๆ เป็นความท้าทายอย่างมาก เวลาพูดถึง legacy system อาจจะไม่ได้มีระบบอะไรมากมายไปกว่าการใช้พนักงานมานั่งโทรศัพท์ตามข้อมูลที ละตัว แล้วก็พิมพ์ลง Excel ส่งอีเมล์ไปถึงทุกคนในบริษัท บ่อยครั้งที่ถึงแม้เราจะติดตั้งระบบรายงานอัตโนมัติ แต่รายงาน Excel ฉบับ handmade นี้ก็ยังคงอยู่ แถมวกกลับมากัดเอาเสียด้วย ตอนที่ผู้ใช้เปรียบเทียบรายงานทำมือกับรายงานอัตโนมัติ แล้วถามว่า “ทำไมตัวเลขมันไม่ตรงกัน ?”
- Driving Adoption : อันนี้ปัญหาต่อเนื่องจากข้อ 2 นะครับ เครื่องมือ BI ที่หรูเลิศอลังการ ทำการวิเคราะห์ได้หลากหลายรูปแบบ drill-down, slice & dice, dashboard, และอื่นๆ บางทีมันก็ “เกิน” ความต้องการของผู้ใช้ับางคน แถมเครื่องมือชั้นดี มักจะมาพร้อมกับความอุ้ยอ้าย โหลดช้า ติดตั้งยาก ใช้งานยาก ต้อง online เท่านั้นถึงจะใช้ได้ ผู้ใช้จำนวนมากลองๆ ดู 2-3 หนแล้วก็หันไปบอกเลขาให้ส่งไฟล์ Excel ทำมือให้อย่างเดิมดีกว่า
- Working through organizations : ปัญหาเรื่องภายในองค์กรก็มีส่วน อันนี้ไม่ได้หมายความถึงเรื่องการเมืองภายในนะครับ แต่แน่นอนที่องค์กรขนาดใหญ่ จะมีการแบ่งเป็นหน่วยธุรกิจที่แตกต่างกัน แต่ละฝ่าย แต่ละแผนก ก็จะมีความต้องการที่แตกต่างกัน เผลอๆ แต่ละแผนกมีเจ้าหน้าที่ IT ของตัวเองเสียอีก บางทีระบบงานที่แต่ละแผนกเลือกใช้ต่างกัน หรือใช้เทคโนโลยีต่างกัน การจะผสานข้อมูลของแต่ละส่วนงานเข้าด้วยกัน เลยไม่ใช่เรื่องง่ายๆ แถมถ้ายังมีเรื่องการเมืองมาเกี่ยวด้วย ยิ่งแย่เข้าไปใหญ่
- There’s no one size fits all : ลักษณะรูปแบบการทำงาน วิธีการตัดสินใจของแต่ละหน่วยงาน ในงานแต่ละแบบ มีความแตกต่างกัน ความพยายามผลักดันให้ใช้ระบบหรือเครื่องมือชนิดเดียวกัน รายงานแบบเดียวกัน ในบางกรณีจึงไม่ใช่สิ่งที่ควรจะทำ ยิ่งองค์กรใหญ่ มีความหลากหลายมากเท่าไหร่ โอกาสที่ BI solution จะแตกลูกออกหลานมาก็ยิ่งมากขึ้นเท่่านั้น อย่างไรก็ตาม ถึงแม้จะเป็นไปไม่ได้ที่ทุกคนจะใช้ระบบแบบเดียวกัน แต่ก็ไม่ได้หมายความว่าเราควรจะมีระบบ หรือเครื่องมือเป็นสิบๆ แบบที่ทำงานคล้ายคลึงกัน แบบนั้นงาน support คงปวดหัวตาย ประเด็นสำคัญคือการหาจุดสมดุล
ผมว่าแต่ละเรื่อง มีความเกี่ยวพันกัน และอาจจะมีดีกรีความยากแตกต่างกันไปในแต่ละองค์กร แต่ละธุรกิจ แต่ความท้าทายเหล่านี้ทำให้ปัญหาเรื่องเทคโนโลยีกลายเป็นเรื่องเล็กน้อยไป เลย แต่ถึงจะยากแค่ไหน ถ้าเราจัดการปัญหาพวกนี้ได้ ผมว่า BI จะเป็น competitive advantage ให้กับธุรกิจได้มากจริงๆ