BzInsight

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

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

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

ในบริษัทขนาดใหญ่ กิจกรรมอย่างหนึ่งที่เสมอขึ้นบ่อยๆ เพื่อกระตุ้นการเติบโต คือการซื้อกิจการ (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 อาจจะไฟธาตุแตกเอาได้ง่ายๆ แถมยังเสียโอกาสที่จะได้ปรับปรุงระบบของเราให้ดีขึ้นอีกด้วย

แต่ละปีพอถึงเวลาต้องวางแผน ว่าจะทำโปรเจ็คไอทีอะไรบ้าง เรื่องที่ชวนปวดหัวอยู่เป็นประจำก็คือ จะเลือกโปรเจ็คอย่างไรดี คนที่ดูแลแผนงาน IT คงเคยพบว่า ฝ่ายขายก็ขอให้ทำไอ้นั่น มาร์เก็ตติ้งต้องการไอ้นี่  CEO อยากให้มีระบบนี้ แถมยังเจอประเภทประกาศกรมสรรพากร ประกาศกระทรวงแรงงาน หรือไอซีที บังคับว่าระบบคอมพิวเตอร์ในบริษัทต้องมีลักษณะตามนี้ๆๆๆ ไม่ทำตามเจอปรับ บางทีก็เจอไฟล์ทบังคับ ไม่ได้อยากทำเล้ย แต่ก็ต้องหาเงินมา upgrade ระบบเพราะพ่อเจ้าประคุณ Microsoft, Oracle, SAP และอื่นๆ เกิดไม่ซัพพอร์ทเวอร์ชั่นเก่าๆ ขึ้นมาเสียเฉยๆ ถ้าไม่ upgrade เดี๋ยวมีปัญหาขึ้นมา หาคนมา patch ให้ไม่ได้เสียอีก

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

หลักการนี้ผมเรียกกันสั้นๆ ว่า FFA ย่อมาจาก Fit, Feasibility, and Attractiveness ก็เป็นวิธีง่ายๆ ในการให้คะแนนข้อเสนอโครงการแต่ละข้อ ตามหลักเกณฑ์ FFA โปรเจ็คไหน ได้คะแนนสูง ก็ทำโปรเจ็คพวกนั้นก่อน เงินกับคนหมดเมือไหร่ ก็ขีดเส้นหยุดพอได้ เกณฑ์การให้คะแนนแต่ละข้อก็ให้เท่าๆ กัน เอาเป็นว่าสเกล 1-5 ก็แล้วกัน คือ คะแนนสูงสุดคือ 5 คะแนนในแต่ละหัวข้อของ FFA ดังนั้นคะแนนเต็มคือ 15 คะแนน

ลองมาดูกันบ้างว่า FFA แต่ละตัวหมายถึงอะไรบ้าง

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

Feasibility : ความเป็นไปได้ทั้งทางด้านเทคนิคและทางเศรษฐศาสตร์
คะแนนสำหรับ feasibility นี่จะให้สำหรับโครงการที่เชื่อว่า “เป็นไปได้” หรือมีข้อพิสูจน์แล้วว่า ทำได้ หรือเป็นไปได้ ยิ่งถ้าเคยทำมาก่อนแล้วนี่คะแนน feasibility นี่ให้ 5 ไปเลย แต่ถ้าเป็นอะไรที่ เจ๋งสุดๆ ทำเป็นเจ้าแรกในโลกเลย อันนี้เอาคะแนนต่ำๆ ไปเพราะความเสี่ยงสูง ความเป็นไปได้นี่ไม่ได้เฉพาะแค่เรื่องทางเทคนิคนะครับ แต่รวมถึงเรื่องความเป็นไปได้ทางการเงินด้วย

Attractiveness : ความน่าสนใจ (จากฝั่งธุรกิจ)
หรือบางทีอาจจะเรียกว่า cool factor ก็ได้ บางโปรเจ็คอาจจะมีความน่าสนใจสูง ถ้ามันสอดคล้องกับวิสัยทัศน์ของธุรกิจ หรือสามารถให้ผลตอบแทนได้สูง ไม่ว่าจะเป็นในรูปของ ROI หรือในรูปของ productivity gain ของพนักงาน แต่ข้อนี้คนที่ให้คะแนนควรจะเป็นคนขอโครงการ เพราะแต่ละคนเห็นความน่าสนใจของแต่ละโครงการไม่เท่ากัน

ถ้าทำบ่อยๆ หรือมีโปรเจ็คมาพิจารณาเป็นจำนวนมากๆ สามารถเขียนคำอธิบายในแต่ละหัวข้อ สำหรับแต่ละคะแนนเอาไว้ได้เลย เช่น โครงการที่จะได้ 5 คะแนนจาก Fit จะต้องมีลักษณะดังนี้ 1,2,3, … ก็ว่ากันไป และในแต่ละข้อ ก็ยังสามารถซอยย่อยลงไปได้อีก แล้วใช้วิธีเฉลี่ยคะแนนรวมกันขึ้นมา หรือจะใช้วิธีถ่วงน้ำหนัก ให้ความสำคัญกับปัจจัยข้อใดข้อหนึ่งเป็นพิเศษก็ได้ แต่มีข้อแม้ว่า ต้องใช้เกณฑ์เดียวกันหมด สำหรับทุกโครงการ ไม่งั้นจะกลายเป็นลำเอียงไป

สายอาชีพของงาน business intelligence มีลักษณะที่แตกต่างจากงาน IT สายอาชีพอื่นตรงที่มีความสัมพันธ์ใกล้ชิดอย่างยิ่งกับประเภทของธุรกิจ ดังนั้นหากคุณสนใจในงานด้าน BI คุณจะต้องมีความรู้ในด้านธุรกิจด้วย

ผมมองงานด้านไอทีกว้างๆ เป็นสามจำพวก ตามลักษณะความผูกพันกับประเภทของธุรกิจ คือ

• งานด้าน infrastructure หรือโครงสร้างพื้นฐาน ซึ่งต้องการความรู้ด้านเทคโนโลยีเฉพาะเจาะจงสูง และไม่ค่อยขึ้นอยู่กับความรู้เกี่ยวกับธุรกิจมากนัก อาทิเช่นงานด้าน Network ด้าน Security ด้าน Database DBA หรือทางด้าน Platform management ถ้าคุณเป็น Certified Oracle DBA คุณสามารถย้ายงานไปมาระหว่างบริษัทประกันภัย โรงงานผลิตฮาร์ดดิสก์ และผู้ให้บริการโทรศัพท์มือถือ ได้อย่างง่ายดาย ตราบเท่าที่ธุรกิจเหล่านั้นใช้ Oracle RDBMS เป็นหลัก

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

• งานสายไอที ที่ต้องการความเข้าใจในกระบวนการทางธุรกิจมาก อาทิเช่น งาน implement ระบบ ERP/CRM หรืองาน implement ระบบ BI ทั้งนี้เนื่องจากงานเหล่านี้ บางส่วนเกี่ยวพันหรืออาจจะต้องมีการปรับเปลียนขั้นตอนการทำงานทางธุรกิจ ถึงจะประสบความสำเร็จ ลักษณะการพัฒนาระบบ BI สำหรับธุรกิจอย่างหนึ่ง อาจมีความแตกต่างอย่างมากกับธุรกิจประเภทอื่น รายงาน KPI หรือ scorecard ก็อาจดูแตกต่างกัน หรือมีนิยามต่างกัน

ดังนั้นถ้าคุณสนใจงานด้าน BI ในลักษณะที่เป็น application development หรืองาน implementation คุณหลีกเลี่ยงไม่ได้ที่จำเป็นจะต้องทำความเข้าใจกับเทคโนโลยีและธุรกิจไปควบคู่กันในลักษณะ dual major เหมือนตอนเรียนในวิทยาลัย

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

• การออกแบบ data model
• การทำ requirement analysis
• การบริหารโครงการ
• การออกแบบ OLAP cube structure
• การปรับแต่ง Oracle BI EE

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

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

สิ่งที่ต้องทำคือ สร้างตารางขึ้นมาตามรูปก่อน โดยให้ technical domain เป็นแถว และ business domain เป็นคอลัมน์ โดยมีข้อแนะนำดังนี้

• เริ่มต้นง่ายๆ ก่อน เลือกจัดกลุ่มทั้ง technical และ business domain แค่ 2-3 รายการที่คุณรู้จักและเข้าใจ
• ระบุส่วนที่คุณมีความถนัดและเชี่ยวชาญที่สุดในปัจจุบัน จัดลำดับไว้มุมซ้ายบน นี่คือจุดที่คุณอยู่ในเวลานี้
• เรียงลำดับทั้ง business และ technical domain ตามความชอบและความสนใจ

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

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

ทีมงานในโครงการด้าน 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 รายใหม่เข้ามาในระบบ ทั้งนี้เพราะเซลล์ซึ่งดูแลลูกค้ารายนี้ ไม่ได้แจ้งกับเจ้าหน้าที่ที่ทำหน้าที่บันทึกข้อมูล ว่าลูกค้ารายนี้มีประวัติอยู่ก่อนแล้ว

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

ฟัง podcast ช่างคุย ในตอนที่ 100 เรื่อง 4 wired articles แล้วให้สะดุดใจ ในเรื่องของรถไฟฟ้ากับแนวคิดการสร้างเครือข่ายพลังงานแบตเตอรี่ คุณ @hongsyok พูดไว้ประโยคหนึ่งที่ผมคิดว่าน่าสนใจมาก นั่นคือ ความพร้อมในการ ‘Commercialize’ หรือพัฒนาให้เกิดผลในเชิงพาณิชย์ได้ของนวัตกรรมใดๆ จะต้องมีองค์ประกอบสามด้านเสมอ นั่นคือความพร้อมทางด้านเทคโนโลยี ทางด้านผู้ับริโภค และทางด้านโครงสร้างพื้นฐาน แวบนั้นผมนึกไปถึงเจ้าเครื่อง Segway ซึ่งเป็นสิ่งประดิษฐืที่มีความพร้อมทางด้านเทคโนโลยี แต่อาจจะยังขาดความพร้อมทั้งทางด้านผู้ใช้ (ที่มีกำลังซื้อ) และที่แน่ๆ คือ infrastructure ไม่เอื้ออำนวย นอกเสียจากจะรื้อแล้วทำทางเดินเท้าใหม่ทั้งหมด ก็เข้าข่ายเดียวกันกับรถไฟฟ้า

กลับมาเข้าเรื่อง Business intelligence กันบ้าง ผมมองว่า ไม่ต่่างกันมากนัก การจะนำ BI เข้ามาใช้ในองค์กรให้ประสบความสำเร็จ ต้องมีองค์ประกอบสามด้านเช่นกัน ที่แตกต่างกันก็คือ ผมมองโครงสร้างพื้นฐาน (network bandwidth, computing power) เป็นส่วนหนึ่งของความพร้อมทางด้านเทคนิค ส่วนที่เพิ่มเข้ามาคือความพร้อม Client ซึ่งในที่นี้หมายถึง ผู้บริหารที่ตัดสินใจจะนำ BI เข้ามาใช้เพิ่มประสิทธิภาพการทำงานในองค์กรนั่นเอง เพราะในงาน BI คนจ่ายตังค์กับคนใช้ มักจะเป็นคนละกลุ่มกัน

บ่อยครั้งที่การตัดสินใจพัฒนา และนำระบบ BI เข้ามาใช้ มีพื้นฐานมาจากความพร้อมทางเทคนิคเพียงอย่างเดียว แต่ละเลยความสำคัญในอีกสองส่วนไป ทำ้ให้เกิดปัญหาทำ report บ้าง ทำ cube บ้างมาเยอะแยะ แล้วก็ไม่มีคนใช้ หรือไม่ก็ใช้ไปๆ ก็เลิกใช้เสียยังงั้นแหละ

ลองมาดูกันบ้างว่า คำถามประเภทไหน ที่น่าจะถามเพื่อวัดถึงความพร้อมในแต่ละด้าน อันนี้เป็นแค่ตัวอย่างนะครับ

Technical Readiness - ความพร้อมทางด้านเทคนิค

• ระบบทำงานได้ถูกต้องและแม่นยำ มีอาการ แฮงค์ ตัวเลขแปลกๆ เพี้ยนๆ บ้างหรือไม่
• ความนำเชื่อถือ หรือ reliability ของระบบ Daily updates ตอนเช้าให้รายงานล่าสุดสม่ำเสมอหรือไม่ หรือว่ารายงานออกช้าเป็นประจำ job failed วันเว้นวัน
• การสนับสนุนทางเทคนิค พร้อมหรือไม่ ใครรับสายจากผู้ใช้ ถ้ามีปัญหา call center รู้หรือไม่ว่าจะตามหาใคร

User Readiness - ความพร้อมด้านผู้ใช้

• ใช้งานระบบใหม่เป็นหรือยัง ผ่านการอบรมมาหรือไม่ รู้หรือไม่ว่าเมื่อไหร่ควรเปิดใช้ cube A แทนที่จะเป็น cube B
• ถ้ามีปัญหา ทราบหรือไม่ว่าต้องติดต่อใคร ไม่ว่าจะเป็นปัญหาเกี่ยวกับตัวระบบ หรือปัญหาเกี่ยวกับข้อมูลที่แสดงให้เห็น
• ทราบหรือไม่ว่า “ความคาดหวัง” ที่เปลี่ยนไปหลังจากใช้ระบบเป็นอย่างไร กระบวนการทำงานบางอย่างจะเปลี่ยนแปลงไปจากเดิมอย่างไรบ้าง รายงานหรือข้ือมูลบางฉบับควรจะถูกยกเลิก หลังจากที่ BI ถูกนำมาใช้

Client Readiness - ความพร้อมด้านผู้บริหาร

• พร้อมที่จะให้งบประมาณ ทรัพยากรบุคคล และการสนับสนุนเพื่อให้ระบบ BI สามารถทำงานได้สำเร็จหรือไม่
• เข้าใจถึง “ต้นทุน” ในระหว่างการติดตั้ง และในระหว่างดำเนินการหรือไม่ ไม่เฉพาะแค่รายจ่ายเป็นตัวเิงิน แต่รวมถึง TCO: Total Cost of Ownership อาิทิเช่น การเปลี่ยนแปลงกระบวนการทำงาน การควบคุมคุณภาพของข้อมูล เป็นต้น
• เข้าใจถึงวิธีการที่จะวัด “ประสิทธิภาพ” ที่เพิ่มขึ้นจากการนำ BI มาใช้งาน

โดยทั่วไปเราก็เคยได้ยินกันว่า Business Intellience หรือระบบ DSS (Decision Support System) ช่วยในการตัดสินใจ ความจริงแล้วผมได้ยินมาตั้งแต่สมัยที่เรียกกันว่า MIS (Management Information System) แล้ว ผมเองก็ท่องมาตั้งเป็นสิบปีว่าระบบ BI ถ้ามีแล้ว ผู้บริหารในองค์กรจะ “ตัดสินใจ” ได้ดีขึ้น แต่จนแล้วจนรอด ก็หาข้อพิสูจน์มายืนยันความเชื่อนี้ไม่ได้ซักที กลายเป็นว่ามีปัจจัยอื่นเข้ามาเกี่ยวด้วย เพราะผู้บริหารบางคน ต่อให้มีข้อมูล มีเครื่องมือดีขนาดไหน พี่ท่านก็ยังเล่นโยนหัวโยนก้อยในการตัดสินใจอยู่ดี กลายเป็นเรื่องของแต่ละคนไป

พอได้มีโอกาสอ่านหนังสือชื่อ Teach your to think ของ Edward de Bono ถึงเริ่มเข้าใจจุดเชื่อมโยง ส่วนที่หายไปคือ “Thinking” หรือกระบวนการคิดนั่นเองครับ ผมสรุปเองได้ว่า BI ไม่ได้ช่วยตัดสินใจโดยตรง แต่ช่วยเพิ่มความสามารถในการคิด

ในขั้นตอนของการคิดพื้นฐาน มีเรื่องหนึ่งที่อธิบายไว้ในหนังสือคือ Broad/Specific vs. General/Detail ตัวอย่างที่มีในหนังสือคือ ให้ลองจินตนาการถึงเหยี่ยวสองตัว ตัวหนึ่งสายตาสั้น อีกตัวสายตาดีมากๆ มองไกลแค่ไหนก็ยังเห็นได้ชัดแจ๋ว ทีนี้เหยี่ยวนี่สามารถกินสัตว์เล็กเป็นอาหารได้หลายอย่าง กบ หนู กับกิ้งก่า เหยี่ยวสายตาดีบินอยู่ีสูงลิบๆ มองลงมาเห็นกบ ก็โฉบลงมากินกบได้สบาย ทำให้ไม่สนใจที่จะกินหนูกับกิ้งก่าเลย ส่วนเจ้าเหยี่ยวสายตาสั้น มองลงมาจะเห็นแค่อะไรเบลอๆ เป็นแค่ “สัตว์อะไรบางอย่างตัวเล็กๆ เคลื่อนไหวได้” ไม่รู้ชัดว่าเป็นอะไร ต้องโฉบลงมาก่อน ถึงจะรู้ บางทีก็เป็นกบ บางทีก็หนูหรือกิ้งก่า

คำถาม คุณคิดว่าเป็นเหยี่ยวสายตาสั้นหรือเป็นเหยี่ยวตาดี ดีกว่ากัน?

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

ในกระบวนการคิด ความสามารถในการมองภาพกว้าง จะส่งผลอย่างมากต่อความสามารถในการคิด ลองพิจารณาสองประโยคนี้ดู

• ฉันต้องการกาวบางชนิดมาติดไม้สองชิ้นนี้เข้าด้วยกัน
• ฉันต้องการวิธีการบางอย่างมาติดไม้สองชิ้นนี้เข้าด้วยกัน

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

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

หนึ่งในลักษณะของผู้นำทางธุรกิจคือ ความสามารถในการเปลี่ยนมุมมองให้เหมาะสมกับสถานการณ์ คือสามารถมองภาพกว้างได้ เราอาจจะเคยได้ยินวลีจำพวก “see the big picture”, “assess the landscape”, หรือ “30,000 feet view” เหมาะสำหรับการคิดแบบสร้างสรรค์ การวางแผนกลยุทธ์ และในขณะเดียวกัน ถ้าจำเป็นก็จะต้องสามารถโฉบลงมาในระดับล่างที่เจาะจงมากขึ้น วลีจำพวก “practical”, “down to earth”, “realistic” พวกนี้สะท้อนความสามารถในการคิดแบบเฉพาะเจาะจง เหมาะสำหรับงานที่มีขั้นตอนชัดเจน งานด้านปฏิบัติการ หรือการแก้ไขปัญหาเฉพาะหน้า

Business Intelligence เข้ามาช่วยตรงนี้แหละครับ ความสามารถที่เรียกว่า “Roll-up” และ “Drill-down” ช่วยให้ผู้บริหารสามารถเลือกมุมมองของข้อมูลสารสนเทศที่มีอยู่ได้ ต้องการเห็นภาพกว้าง ก็ roll-up มองภาพรวมการเติบโตของทั้งบริษัท ทุกกลุ่มสินค้า ทุกแผนก เทียบแนวโน้ม 3 ปี 5 ปีที่ผ่านมา เอา visualization มาใช้แปลงข้อมูลจำนวนมากให้ง่ายต่อการเข้าใจ นำเสนอในรูปกราฟหรือแผนภูมิ และถ้าจำเป็นก็สามารถเจาะลึกลงรายละเอียด drill-down ลงไปได้ เอาสินค้าตัวนี้ ลูกค้ารายนี้ ไตรมาสนี้เมื่อวานนี้

มุมมองทั้งสองแบบ ส่งผลต่อการตัดสินใจทั้งสิ้น เพียงแต่อยู่ในระดับที่แตกต่างกัน ถ้าเป็นการวางแผน วิเคราะห์ มักจะใช้มุมมองที่กว้าง แต่ถ้าเป็นการตัดสินใจปฎิบัติงาน มุมมองเฉพาะเจาะจง จะช่วยในการตัดสินใจได้มากกว่า

ไปอ่านบล็อกเรื่อง Automate the Wrong Sales Process And Die More Quickly แล้วสะดุดใจกับภาพนี้มาก เนื้อหาในบล็อกคุยเรื่องการ automate sales process แต่ผมคิดว่ารูปนี้ก็สื่ออะไรได้หลายอย่าง แนวความคิดเรื่องประสิทธิภาพ (efficiency) กับประสิทธิผล (effectiveness) ใครที่อ่านหนังสือจำพวก self-help หรือหนังสือหมวดบริหาร คงจะคุ้นเคยกันเป็นอย่างดี

เห็นรูปนี้ปุ๊บ ผมคิดถึงคำนี้เลยครับ “อย่าฉลาดในเรื่องโง่ๆ” การพยายาม automate หรือหาวิธีทำงานอะไรบางอย่างให้มีประสิทธิภาพสูงๆ โดยไม่ได้ดูเลยว่า “ควร” จะทำเรื่องนั้นหรือเปล่า ตัวอย่างคงมีเยอะแยะรอบๆ ตัวเราเต็มไปหมด เริ่มจากตัวเองก่อนแล้วกัน เดี๋ยวผมเองก็คงต้องกลับบ้านไปส่องกระจกดูว่า เรากำลังทำเรื่องโง่ๆ อย่างฉลาดเฉลียวอยู่หรือเปล่า

เมื่อประมาณ 2-3 สัปดาห์ก่อน มีการประชุมเพื่อทบทวนการทำโครงการ BI หาบทเรียน (lessons learned) เพื่อหลีกเลี่ยงความผิดพลาดแบบเดิมในอนาคต ก็มีการพูดคุยกันหลายประเด็น แต่ที่ผมจะยกมาคุยให้ฟังวันนี้คือเรื่อง Common KPI (Key Performance Indicator)

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

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

• KPI ตัวไหนที่ควรจะนำมาใช้ในการวัดผล มีวิธีการวัดผลเยอะแยะมากมาย ไม่ว่าจะเป็น ยอดขาย อัตราการเติบโตของยอดขาย กำไร อัตราขยายตัวของกำไร กระแสเงินสด ส่วนแบ่งการตลาด ถ้ามองในแง่ขององค์กร อาจจะประกอบไปด้วย จำนวนพนักงาน อัตราการลาออก ผลสำรวจความนิยม หรือผลสำรวจความพึงพอใจของพนักงาน
  • แต่ละหน่วยงานควรจะมี KPI ไม่มากเกินไป เพราะจะเสียเวลาในการวัดผลมากกว่าเวลาสร้างธุรกิจ แต่ประเด็นสำคัญคือ KPI หลัก ควรจะมีลักษณะที่เหมือนกันในทุกหน่วยย่อยขององค์กร เพื่อให้ผู้บริหารระดับสูง (อาจจะเป็น CEO ของบริษัทในเครือ) สามารถเปรียบเทียบ “ผลงาน” ระหว่างสองบริษัทได้ โดยใช้บรรทัดฐานเดียวกัน
• ในแต่ละ KPI นอกจากจะมีชื่อเรียกเหมือนกันแล้ว ต้องให้แน่ใจด้วยว่า “นิยาม” หรือตรรกะที่ใช้ในการคำนวณค่า KPI นั้นมีฐานเดียวกัน เพื่อให้การเปรียบเทียบ KPI ระหว่างแต่ละหน่วยงานย่อยมีความถูกต้อง
  • ยกตัวอย่างเช่น หากมีการกำหนดให้ KPI คือ อัตราการเติบโตของยอดขาย เทียบกับปีที่แล้ว แล้วบริษัทสาขาในประเทศไทย มีอัตราการเติบโต 11% เทียบกับสาขาในมาเลเซียที่มีอัตราการเติบโตที่ 25% ถ้าดูแค่นี้ก็ดูเหมือนว่าที่มาเลเซียเติบโตมากกว่า แต่ถ้าให้ข้อมูลเพิ่มเติมว่า ในปีที่ผ่านมามีการซื้อกิจการจากบริษัทอื่นเข้ามาร่วมด้วยบางส่วน แต่ประเทศไทยรายงานผลโดยแยกอัตราการเติบโตจากการซื้อกิจการ ออกไป เหลือแต่อัตราการเติบโตส่วนตัว (Organic Growth) แต่ทางมาเลเซียรวมยอดของบริษัทใหม่เข้าไปด้วย ทำให้ดูเผินๆ เหมือนจะเติบโตมากกว่า แต่ความจริงอาจไม่เป็นเช่นนั้น

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

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

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

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

สำหรับท่านที่ยังไม่รู้จักว่า Mind Map คืออะไร มีประโยชน์อย่างไร และใช้งานอย่างไร ผมอยากแนะนำให้อ่านหนังสือเล่มนี้ How to Mind Map วิธีเขียน Mind Map ฉบับเจ้าสำนัก โดยโทนี่ บูซาน

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

ข้อมูลเพิ่มเติมเกี่ยวกับ Mind Map

http://www.mindmap.in.th/
http://en.wikipedia.org/wiki/Mind_map