BzInsight

สายอาชีพของงาน 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

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

• มีการส่งกำหนดการล่วงหน้าหรือไม่? (ประชุมกันเรื่องอะไร เพื่ออะไร ที่ไหน เมื่อไหร่)
• คนที่เข้าร่วมประชุม ครบถ้วนและถูกต้องแล้วหรือไม่? ถ้าขาดคนสำคัญบางคนไป บางทีก็ควรเลื่อนมากกว่าเพราะไม่เกิดประโยชน์อะไรเลย
• ถ้ามีเอกสารที่ต้องอ่านก่อน เพื่อทำความเข้าใจล่วงหน้า มีการส่งเอกสารล่วงหน้าก่อน 48 ชั่วโมงหรือไม่?
• ผู้เข้าประชุม มีการอ่านเอกสารล่วงหน้าหรือไม่? แทนที่จะต้องเสียเวลาระหว่างประชุมมาเล่าถึงที่มาที่ไป ส่งเอกสารให้อ่านก่อนล่วงหน้า เวลาประชุมก็พุ่งประเด็นไปที่การอภิปรายกันได้เลย ไม่ต้องเกริ่นกันให้เสียเวลาอีก
• เริ่มประชุมตรงเวลาหรือไม่?
• เมื่อเข้าร่วมประชุม คุณตั้งสมาธิอยู่ในการประชุมหรือไม่? ขจัดสิ่งรบกวนจำพวก email, chat, twitter
• ทุกคนที่มีส่วนได้ส่วนเสีย ได้มีโอกาสแสดงความคิดเห็นแล้วหรือไม่?
• ได้มีการตัดสินใจอย่างใดอย่างหนึ่ง (ถ้าเป็นการประชุมเพื่อตัดสินใจ) โดยไม่เสียเวลาในการอภิปรายกันจนยืดยาวเยิ่นเย้อเกินจำเป็นหรือไม่?
• ใครเป็นคนบันทึกผลการประชุม?
• สิ่งอำนวยความสะดวกทำงานได้ดีหรือไม่? คุณภาพเสียงโทรศัพท์ (กรณีประชุมทางไกล) ห้องประชุม โปรเจ็คเตอร์ และอื่นๆ
• มีเวลาพักบ้างเป็นช่วงๆ ทุก 90 นาที

คราวที่แล้วเอาสไลด์ชุด 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 ในทีมเบสบอลด้วย เช่นการตัดสินใจว่าจะเลือกหาผู้เล่นสำรองจากแหล่งไหน เป็นต้น น่าสนใจดีทีเดียว