BzInsight

ในระหว่างการประชุมทำ project review เมื่อกลางสัปดาห์ที่ผ่านมา ทางโปรเจ็คสปอนเซอร์ ซึ่งเป็น sales director ก็รีวิวความคืบหน้าของโครงการ ทางทีมทำ solution เสนอรายงาน 5 แบบกับ OLAP cube อีกหนึ่ง พอท่านผู้ใหญ่เห็นรายงาน ก็เริ่มเอ่ยปากขอ เพิ่มคอลัมน์ตรงนี้ได้ไหม ตัวเลขยอดขายนี่ นอกจากเป็น absolute volume แล้วขอเป็น index vs year ago ด้วยเป็นต้น ซึ่งแน่นอน ว่าโดยทางเทคโนโลยีแล้ว เป็นเรื่องง่ายมาก

ก่อนที่ทาง technical team leader จะมีโอกาสอ้าปากตอบ ผมต้องรีบชี้แจงว่า รายงาน 5 แบบนี้ ได้มาจากการทำ focus group discussion กับกลุ่มผู้ใช้ ผ่านการทะเลาะถกเถียงกันมานาน เพื่อให้ได้รายงานเพียงแค่ 5 แบบ (แทนที่จะเป็น 30 แบบ เพราะแต่ละคนต่างก็มี “ความชอบ” แตกต่างกัน)   ความจริงแล้ว เทคโนโลยีไม่ใช่ประเด็นหลัก แต่เราอยากได้รายงาน 5 ฉบับที่ 95% ของผู้ใช้เรียกใช้งานทุกวัน ทุกสัปดาห์ มากกว่าจะมีรายงานมากมายถึง 30 แบบ แต่ว่าแต่ละแบบมีคนใช้อยู่ไม่กี่คน กระจัดกระจายกันไป

ผมชี้แจงปัญหาที่ผมเรียกเอาเองว่า report proliferation คือการที่รายงานต่างๆ มีจำนวนเพิ่มมากขึ้นเรื่อยๆ อย่างรวดเร็ว เพียงเพราะว่าเครื่องมือด้าน business intelligence หรือความสามารถของคนไอที ที่ “ทำอะไรก็ได้ แบบไหนก็ได้ ใครขออะไร ได้หมด” และโดยส่วนมากความต้องการที่แตกต่างกันในแต่ละรายการก็เป็นเพียงแค่ want หรือ preference มากกว่าจะเป็นความต้องการทางธุรกิจจริงๆ

ลองนึกภาพพนักงานเข้าใหม่ มาทำงานวันแรก เริ่มใช้รายงานเป็นครั้งแรก เปิดหน้า portal เข้ามาเจอรายงาน 30 ฉบับก็ตาเหลือกแล้ว ไหนจะต้องคอยมาจำอีกว่า ถ้าจะคุยกับคนนี้ต้องใช้รายงาน A จะคุยกับคนนั้นใช้รายงาน B ทั้งๆ ที่เนื้อหาในรายงานโดยเนื้อแท้แล้ว ก็มาจาก cube หรือมาจาก datamart อันเดียวกันนั่นเอง

เราสรุปกันได้ว่า คำขอของ sales director ท่านนั้นก็จะผ่านไปสู่กระบวนการของ change management board เหมือนคำขออื่นๆ แถมดูเหมือนท่านจะสนับสนุนแนวคิด less is more แบบนี้เสียด้วย

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

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

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

ภาพจาก TDWI ใครสมัครรับจดหมายข่าวจาก TWDI (The Data Warehousing Inistitute) คงได้รับโปสเตอร์ฉบับนี้แล้วนะครับ ใครยังไม่ได้ก็สมัครขอรับ โปสเตอร์ได้ฟรีครับ คลิ้กตามลิงค์ในภาพไปได้เลย แค่ลงทะเบียนกับเขาเสียหน่อย แล้วก็สามารถดาวน์โหลดมาได้เป็นไฟล์ PDF มีสองขนาด คือ ขนาด Letter (8×11) กับขนาดใหญ่ 20×30 นิ้ว เอาไปพิมพ์ปะข้างฝากันได้ตามสะดวก

ถึงแม้ว่านิยามของ MDM หรือ master data management จะยังไม่นิ่งพอ คือแต่ละสำนักต่างก็พยายามตั้งนิยามของตัวเองขึ้นมา แต่ในภาพโปสเตอร์นี้จะช่วยให้มองเห็นภาพกว้างได้เป็นอย่างดี เอาเป็นว่าผมมาย่อยให้ฟังตามความเข้าใจของผมเองก็แล้วกัน ผมจะซูมเข้าไปในแต่ละส่วนของโปสเตอร์ (คลิ้กที่ภาพเพื่อขยาย) ถ้าใครอยากได้ฉบับเต็มก็ไปสมัครเอา (ถ้าไม่สะดวกจริงๆ เขียนเมล์มาขอแล้วกันครับ ไม่อยากเปิดให้ดาวน์โหลด เพราะของเขามีสปอนเซอร์อยู่)

โดยภาพรวมแล้ว MDM จะประกอบด้วยการทำงานร่วมกันระหว่างสามกลุ่มคือ People, Practices, และ Automation

• People: งาน MDM จะมีความเกี่ยวข้องข้ามแผนกและข้ามระบบ ประเด็นสำคัญคือการทำความเข้าใจที่ตรงกันเกี่ยวกับข้อมูลอ้างอิงที่ใช้ร่วมกัน รวมถึงระบบงานไอทีที่แต่ละแผนกใช้งานด้วย ถึงแม้งาน MDM จะเป็นปัญหาเชิงเทคนิค แต่การแก้ไขปัญหาจะต้องอาศัยการจัดการองค์กรเข้ามาเกี่ยวข้องด้วย

• Practices: การนำ MDM ไปใช้งานยังสามารถแบ่งออกเป็นหลายรูปแบบ อาิทิเช่นในระดับปฏิบัติการ การใช้เพื่อการวิเคราะห์และการใช้ในระดับทั่วทั้งองค์กร

• Automation: งาน MDM โดยทั่วไปจะมีความซับซ้อน ดังนั้นการใช้ระบบซอฟต์แวร์อัตโนมัิติเข้ามาช่วยงาน จึงมีความจำเป็น ไม่ว่าจะเป็นส่วนจัดเก็บข้อมูล ส่วนประสานงาน หรือระบบ front-end ที่ช่วยในการจัดการข้อมูลอ้างอิง

คราวนี้ก็มาเจาะกันทีละส่วนก็แล้วกันนะครับ ส่วนแรกคือ

Cross-Functional Collaboration เป็นการทำงานร่วมกันข้ามแผนก โดยเน้นไปที่การทำความตกลงเรื่องนิยามของข้อมูลอ้างอิง และกระบวนการทำงานเกี่ยวกับข้อมูลอ้างอิง ประกอบไปด้วยการมีทีมงานแบบ cross-functional team ประกอบด้วยทั้งฝ่าย business และ IT ต้องมี Organizational structure หรือโครงสร้างองค์กรที่เข้ามารองรับและสนับสนุนการทำงานของทีมนี้ อาจจะอยู่ในรูปของ Governance committee หรือ  center of excellence ก็ได้ ลักษณะการทำงานจะต้องเป็นแบบ Collaboration ในการตกลงนิยามร่วมกันของข้อมูลอ้างอิง รวมไปถึงความเป็นเจ้าของข้อมูลด้วย และส่วนสุดท้ายคือการ Oversight หรือดูแลการเปลี่ยนแปลงเกี่ยวกับนโยบายข้อมูลอ้างอิงภายในองค์กร

Cross-System Implementation เป็นงานในส่วนที่จะต้องมีการปรับเปลี่ยนระบบงาน IT ที่มีอยู่เดิม ให้สอดคล้องและสนับสนุนมาตรฐานข้อมูลอ้างอิงใหม่ที่กำหนดขึ้น ซึ่งรวมไปถึงการจัดการข้อมูลที่มีอยู่เดิม การพัฒนาหรือปรับแก้ระบบบางส่วน การทดสอบการทำงานร่วมกัน หลายองค์กรเลือกวิธีที่ง่ายกว่า โดยการจัดหาระบบแอพลิเคชันเพื่อการจัดการด้าน MDM โดยเฉพาะ องค์ประกอบที่ต้องพิจารณาเปลี่ยนแปลงแก้ไข ประกอบด้วย Data Modeling ซึ่งนอกจากตัวข้อมูลอ้างอิงแล้ว hierarchy หรือวิธีในการสรุปข้อมูลตามลำดับขั้นก็จำเป็นต้องปรับให้สอดคล้องกับมาตรฐานด้วย Meta Data Management ข้อมูลอ้างอิงอาจจะถูกจัดการโดยการใช้เทคโนโลยีของ meta data ได้ Data Quality เป็นเรื่องสำคัญมากสำหรับข้อมูลอ้างอิง ทั้งในแง่ของการสอดคล้องกับมาตรฐานข้อมูล และกระบวนการตรวจสอบคุณภาพ Data Integration ต้องมีการใช้เทคโนโลยี integration เพื่อให้มีข้อมูลอ้างอิงมีการแพร่กระจายไปยังระบบต่างๆ ที่ต้องการใช้งานได้ และท้ายที่สุดคือ Data profiling หรือการจัดทำรูปแบบข้อมูลจะต้องสามารถครอบคลุมในทุกระบบที่เกี่ยวข้อง

Operational MDM หรือระบบจัดการข้อมูลอ้างอิงเพื่อการปฎิบัติงาน นี่เป็นหนึ่งในรูปแบบการใช้งาน MDM คือเพื่อให้กระบวนการทำงานในระดับปฎิบัติการมีความสอดคล้องกัน ในระหว่างระบบแอพลิเคชันพื้นฐานหลายๆ ระบบ (อาทิเช่น ERP, CRM, และ SCM) เนื่องจากนิยามของข้อมูลอ้างอิงเพื่อการปฎิบัติการ มักจะไม่ค่อยเปลี่ยนแปลงบ่อยนัก ทำให้นิยามข้อมูลอ้างอิงใน MDM ก็ไม่ต้องเปลี่ยนแปลงบ่อยเช่นกัน อย่างไรก็ตาม ความเร็วในการทำงานของระบบปฏิบัติการเหล่านี้เป็นแบบ real-time ดังนั้น Operational MDM จึงต้องทำงานในลักษณะั real-time ไปด้วย ระบบงานที่นำ Operational MDM ไปใช้ประกอบไปด้วย CRM and ERP instances ในกรณีที่มี ERP/CRM มากกว่าหนึ่งระบบ MDM จะเป็นส่วนเชื่อมโยงแต่ละระบบเข้าด้วยกัน  SCM Applications โดยเฉพาะอย่างยิ่งข้อมูลผลิตภัณฑ์ที่แตกต่างกันจากผู้ผลิตแต่ละราย การใช้ MDM จะ่ช่วยให้ข้อมูลสินค้าที่แตกต่างกันนั้น มีความสอดคล้องกันได้ Financial Systems การใช้งาน MDM ในระบบบัญชีและการเิงิน จะช่วยให้สามารถปิดงบได้เร็วขึ้นและรายงานการเงินมีความถูกต้องสูงขึ้น และสุดท้ายคือ Independent MDM application ซึ่งถึงแม้จะมีการใช้ใน analytic MDM แต่โดยมากก็มักจะมีการติดตั้งอยู่กับระบบที่เกี่ยวข้องกับระดับปฏิบัติการ

Analytic MDM ระบบจัดการข้อมูลอ้างอิงเพื่อการวิเคราะห์ เป็นอีกรูปแบบหนึ่งของการใช้งาน MDM ซึ่งแต่เดิมก็เป็นส่วนหนึ่งของระบบคลังข้อมูล (data warehouse) มาก่อนแล้ว ความจำเป็นของ MDM เพื่อการวิเคราะห์ข้อมูล จะอยู่ในจุดสมดุลระหว่างความต้องการข้อมูลที่ถูกต้อง และความต้องการวิเคราะห์ข้อมูลในลักษณะที่แตกต่างไปจากเดิม เช่นการ aggregate ข้อมูลต่าง hierarchy นิยามข้อมูลใน Analytic MDM จะเปลี่ยนแปลงไปได้เร็ว ขึ้นอยู่กับความต้องการใช้ หรือโมเดลการวิเคราะห์ที่ต้องการ การใช้งาน Analytic MDM จะพบใน Data warehouse and marts และใน Reporting อีกทั้งยังพบได้มากในการสร้างแอพลิเคชันอย่าง Customer Data Hubs หรือ Product Data Hubs เพื่อสร้างมุมมองที่สมบูรณ์รอบด้านของข้อมูลเกี่ยวกับลูกค้าและสินค้า

Enterprise MDM ระบบจัดการข้อมูลอ้างอิงในระดับองค์กร กำลังเป็นแนวโน้มที่จะทำให้ MDM กลายเป็นส่วนหนึ่งของโครงสร้างพื้นฐานของระบบสารสนเทศภายในองค์กร และเป็นส่วนสำคัญในการเชื่อมโยงการทำงานระหว่างแผนกและระหว่างระบบไอทีต่างๆ รูปแบบการใช้งานจะประกอบไปด้วย Single MDM Infrastructure รูปแบบการใช้งาน Operation MDM และ Analytic MDM มีความแตกต่างกัน จนทำให้ในหลายๆ องค์กร การพยายามที่จะสร้างโครงสร้างพื้นฐานสำหรับ MDM แบบเดียว เพื่อตอบสนองความต้องการทั้งสองส่วน เป็นไปได้ยาก แต่การมี MDM แบบเดียวก็ยังเป็นลักษณะการใช้งานที่เป็นที่ต้องการอยู่เสมอ MDM Application หากโครงสร้างพื้นฐานด้าน MDM มีอยู่แล้ว จะเกิดการใช้งานแอพลิเคชันใหม่ๆ ตามมา อาทิเช่นแอพลิเคชันทีึ่ใช้จัดการข้อมูลสินค้าหรือข้อมูลลูกค้าแบบครบวงจร เป็นต้น Embeded MDM เป็นลักษณะการใช้งาน MDM ในท้ายที่สุดแล้ว ควรจะสามารถสนับสนุน web services หรือ SOA (Service-Oriented Architecture) เพื่อให้บริการด้าน MDM กลายเป็นบริการที่สามารถเรียกใช้ได้จากระบบและแพลตฟอร์มที่หลากหลาย

ส่วนสุดท้าย เป็นองค์ประกอบที่ใช้ประสานแต่ละกลุ่มเข้าด้วยกัน เรียกว่า MDM Automation via software โดยการใช้ซอฟต์แวร์ช่วยการทำงานร่วมกันของส่วนต่างๆ หรือระหว่างสมาชิกในทีมให้เป็นไปโดยอัตโนมัติ ปัจจัยสำคัญประกอบไปด้วย Processes ระบบซอฟต์แวร์ต้องสามารถสนับสนุนกระบวนการทำงานได้ โดยมากมักจะอยู่ในรูปของ work flow แอพลิเคชัน ที่สอดคล้องกับนโยบายการควบคุมข้อมูลอ้างอิง โดยโปรแกรม work flow จะช่วยให้การขอเพิ่ม เปลี่ยนแปลงแก้ไขข้อมูล ผ่านหน่วยงาน และขั้นตอนการอนุมัติต่างๆ ได้อย่างราบรื่น Repositories หรือส่วนเก็บข้อมูล ซึ่งในที่นี้ไม่ได้หมายความถึงแค่ตัวข้อมุลอ้างอิงเท่านั้น แต่ยังหมายรวมถึง เอกสาร นโยบาย โครงสร้างข้อมูล ผังการทำงาน และอื่นๆ อีกมาก Services หรือบริการที่เกี่ยวข้องกับการจัดการข้อมูล  มีความจำเป็นอย่างยิ่งในระบบที่ทำงานข้ามระบบงาน อาทิเช่น บริการตรวจสอบความถูกต้องของข้อมูล บริการแปลงข้อมูลให้ได้มาตรฐาน หรือการจับคู่ข้อมุล เป็นต้น บริการเหล่านี้อาจจะอยู่ในรูปของ API หรืออาจจะเป็น web services ก็ได้

สถานการณ์ความรุนแรงดูไม่น่าไว้วางใจเท่าไหร่ องค์กรหลายแห่งก็เริ่มนำ Communication Tree หรือที่เรียกกันย่อๆ ว่า comm.tree ออกมาใช้กันแล้ว comm tree เป็นการสื่อสารภายในองค์กร ในภาวะฉุกเฉินหรือนอกเวลาทำการ วัตถุประสงค์หลักคือเพื่อตรวจสอบความปลอดภัยของพนักงาน และสื่อสารข่าวสารสำคัญภายในองค์กร ในกรณีฉุกเฉินที่การสื่อสารทั่วไปอาจติดขัด หรือล่าช้าไม่กันการ

ภาพจาก ICT4D { ict . or . th } ข่าวไอซีทีเพื่องานพัฒนาสังคม

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

แต่ละคนในองค์กร จะถูกติดต่อในกรณีฉุกเฉินและเมื่อได้รับการติดต่อ แต่ละคนต้อง

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

หากออกแบบ communication tree ได้ดี จะช่วยให้การตรวจสอบสถานะความปลอดภัยของเจ้าหน้าที่ในองค์กร ทำได้อย่างรวดเร็วและมีประสิทธิภาพ อีกทั้งยังสามารถใช้สื่อสารข้อความฉุกเฉินได้อาทิเช่น บริษัทปิดทำการ เป็นต้น ในอดีตที่ผ่านมา มีหลายเหตุการณ์ที่สังเกตได้ว่า communication tree มีบทบาทอย่างมากในภาวะไม่ปกติ ไม่ว่าจะเป็นช่วงการเกิดสึนามิ (เกิดเหตุเช้าวันอาทิตย์) เหตุการณ์วางระเบิดในช่วงวันหยุดปีใหม่ รวมไปถึงการปฎิวัติเมื่อ 2 ปีที่แล้ว

ข้อควรพิจารณาในการจัดทำ communication tree

• หมายเลขโทรศัพท์ที่ติดต่อได้ ควรจะมีทั้งโทรศัพท์มือถือและโทรศัพท์บ้าน
• communication tree จะต้องจัดทำไว้ก่อนล่วงหน้า รวมถึงการสื่อสารให้คนในองค์กรเข้าใจวิธีปฎิบัติด้วย ทุกคนในองค์กรต้องรู้ว่า ใครจะติดต่อเขาและเขาต้องติดต่อใครต่อ
• ต้องมีการอัพเดตข้อมูลใน comm tree ให้ทันสมัยอยู่เสมอ พนักงานเข้าใหม่ ลาออก เปลี่ยนหมายเลขโทรศัพท์ เป็นต้น
• ถ้าเป็นไปได้ ควรจัดเตรียม hot line สายหนึ่ง (มักจะเป็นผู้จัดการฝ่ายบุคคล หรือ corperate security officer) ไว้สำรองเสมอ
• communication tree ถือเป็นเอกสารที่เป็นความลับ การกระจายข้อมูลให้พนักงานแต่ละคน ควรทำด้วยความรอบคอบ พนักงานแต่ละคน จำเป็นต้องทราบเฉพาะสายการสื่อสารที่เขาเกี่่ยวข้องด้วยเท่านั้น และไม่จำเป็นต้องทราบสายการสื่อสารของคนอื่น (รวมถึงข้อมูลส่วนตัวของผู้อื่นที่ไม่เกี่ยวข้องเช่นหมายเลขโทรศัพท์บ้าน)

คุยกับน้องสาวที่ทำงานเป็น IT consult ที่กำลังจะเปลี่ยนงานเร็วๆ นี้ น่าแปลกใจที่พบว่าหลายๆ บริษัทที่พบปัญหาสมองไหล หรือพนักงานลาออกเป็นจำนวนมาก ไม่ได้มีการทำ exit interview หลายคนยังไม่รู้เลยด้วยซ้ำว่าอะไรคือ exit interview

ตามความเข้าใจของผม exit interview เป็นขั้นตอนหนึ่งของงานบริหารงานบุคคล เมื่อมีพนักงานในบริษัทต้องการลาออก ผู้จัดการฝ่ายบุคคลจะทำการสัมภาษณ์พนักงานคนนั้น เพื่อให้ทราบถึงสาเหตุที่ลาออก และจะได้นำมาปรับปรุงสภาพแวดล้อมในองค์กรต่อไป ข้อสำคัญคือ การทำงานสัมภาษณ์เมื่อออกจากงานนั้น ควรจะทำโดยฝ่ายบุคคล แทนที่จะเป็นหัวหน้างานโดยตรง เพราะในหลายๆ กรณีหัวหน้างานอาจจะไม่ทราบเหตุผลที่แท้จริง ผมยังจำคำพูดของ HR manager ที่เคยเล่าให้ฟังนานมาแล้วได้ว่า

They join the company, but they quit their manager

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

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

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

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

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

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

ท้ายนี้มีลิงค์มาฝากครับ หากต้องการทราบรายละเอียดเพิ่มเติมเกี่ยวกับการทำ exit interview
http://www.insightexit.com/index.html

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

การบริหารข้อมูลอ้างอิง (Master Data Management - MDM) เป็นองค์ประกอบหนึ่งที่สำคัญมากสำหรับการจัดการคุณภาพของข้อมูลโดยรวม โดยถือเป็นส่วนประสานงาน ที่เชื่อมโยงองค์ประกอบอื่นของงาน BI เข้าด้วยกัน

โดยนิยาม การบริหารข้อมูลอ้างอิง หมายถึง “กลุ่มของแนวทางปฏิบัติ และวิธีการ ในการทำให้ข้อมูลอ้างอิงของบริษัท มีความถูกต้องเที่ยงตรง สอดคล้องกันทั้งภายในระบบ และระหว่างระบบต่างๆ ในองค์กร”

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

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

ปูพื้นกันเสียหน่อย จะได้เห็นภาพและคุยกันต่อได้สะดวกขึ้น บริษัทที่ผมทำงานอยู่เป็น global company (Fortune 500) เรามีแผนก IT ของเราเองที่รวมศูนย์การทำงาน ระบบหลักๆ มีลักษณะเป็น enterprise system ทั้งสิ้น รวมถึง business intelligence และ reporting service ด้วย ผมดูแลระบบ global solution ด้าน BI อยู่ระบบหนึ่ง ทำหน้าที่คอย “ขาย” ระบบให้กับบริษัทย่อยในเครือในแต่ละประเทศ โดยมีทีมสนับสนุนที่คอยพัฒนาระบบ แน่นอนที่เรา outsource งานออกแบบและพัฒนา โดยที่มี vendor ที่ให้บริการงานออกแบบและพัฒนามีลักษณะเป็น strategic partner คือเรียกว่าเชื่อใจกันได้ ซึ่งก็เป็นบริษัท IT ขนาดใหญ่ๆ ทั้งนั้น บางรายก็เป็นเจ้าของเทคโนโลยีด้วยซ้ำ

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

แต่นั่นเป็นสิ่งที่ลำบากที่จะโน้มน้าวให้ผู้บริหารในแต่ละประเทศ ยอม “จ่ายแพงกว่า” เพื่อให้ได้ระบบ BI ที่สอดคล้องกับมาตรฐานในด้าน scalability, reliability และ interoperatibility ซึ่งหมายถึงการใช้เทคโนโลยีราคาแพง โดยเวนเดอร์ราคาแพง ในขณะที่แต่ละประเทศสามารถหา BI vendor หรือแม้แต่ BI consultant เดี่ยวๆ มาทำระบบให้ประเทศนั้นๆ ในราคาเพียงแค่ 1 ใน 10 หรืออาจจะแค่  1 ใน 20 ของราคาที่ต้องจ่ายให้แผนก IT กลาง และสิ่งที่ได้คือ ระบบ BI หรือ reporting ที่สามารถทำงานได้ ตอบสนองความต้องการของผู้ใช้ที่จ่ายเงินในครั้งแรกได้ แต่ไม่ยั่งยืน หรือไม่สามารถต่อยอดต่อไปได้ และที่สำคัญคือสร้างความวุ่นวายเป็นอย่างมากในการจัดการข้อมูลโดยรวม เพราะเกิด shadow systems ขึ้นในแต่ละประเทศย่อยๆ ผู้ใช้ใช้เวลาส่วนใหญ่เสียไปในการอธิบายว่าตัวเลขในรายงานจาก enterprise system ไม่สอดคล้องกับตัวเลขจาก local system

มองในแง่บวก นี่เป็นโอกาสของ BI consultant หรือ BI vendor รายย่อย ถ้าเราจะสามารถเบียดเข้ามาแข่งกันในตลาด enterprise ได้ ผมมองคร่าวๆ ว่าถ้ามี vendor ที่มีคุณสมบัติเหล่านี้ และเสนอราคาที่ถูกกว่า strategic partner แต่สามารถตอบสนองความต้องการได้ทั้งสองฝั่ง คุณสมบัิติที่ว่าคือ

1. ความสามารถในการสื่อสาร แน่นอนครับ ด่านแรกเลยคือภาษาอังกฤษ เหตุผลเดียวเลยที่ตลาด outsource ของฟิลิปปินส์เติบโตมากกว่าไทย คือประเทศเค้าใช้ภาษาอังกฤษได้ แต่ไม่ได้หมายความว่าแค่ฟังพูดอ่านเขียนภาษาอังกฤษได้แล้วจะทำงานได้นะครับ จะต้องสามารถสื่อสารให้ได้ใจความ กระชับ เหมาะกับผู้รับสาร และทันเวลาด้วย
2. พื้นฐานการบริหาร ปัญหาใหญ่อีกประการของผู้ให้บริการรายย่อย คือขาดทักษะในการบริหารโครงการ ทำให้ไม่สามารถส่งมอบงานออกแบบและพัฒนาได้ตามเวลา
3. ความเข้าใจในความต้องการในระดับ enterprise level อย่าง ที่กล่าวมาแล้วข้างต้น มันไม่ยากที่จะหาใครซักคนมาพัฒนาระบบรายงานเล็กๆ สำหรับผู้ใช้ 20-100 คน แต่รายงานเดียวกันนั้นถ้าเราต้องการระบบที่เสถียรและสามารถขยายใหญ่ขึ้นได้ เพื่อรองรับการใช้งานพร้อมๆ กันเป็น 1000 คน โดยไม่ต้องมีเจ้าหน้าที่มาคอยนั่งไล่แก้บั๊ก หรือคอยรันโปรเซสทุกๆ วัน และสามารถขยายเพิ่มเติมความสามารถใหม่ได้ โดยไม่ต้องรื้อระบบมาเขียนใหม่ทั้งหมด จำเป็นจะต้องเข้าใจว่า enterprise system ต้องการอะไรบ้าง
4. ความรู้ในเทคโนโลยีเฉพาะด้าน แต่ละเทคโนโลยีแพลตฟอร์ม ต่างก็มีความรู้จำเพาะของตัวเอง ซึ่งต้องอาศัยประสบการณ์และทักษะที่มากพอสมควร ตัวอย่างเช่่นคำสั่ง SQL หรือ MDX ที่เขียนง่ายๆ แต่หากนำไปใช้รันบนเครื่องขนาดใหญ่ที่เป็น grid หรือ cluster จะต้องมีการ tuning คำสั่งเหล่า่นั้นเพื่อให้สามารถใช้ความสามารถของ grid หรือ cluster เหล่านั้นได้อย่างเต็มที่

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

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

ในการพิจารณาเลือกระบบงานหรืออุปกรณ์ทางด้าน IT การคำนวณเปรียบเทียบตัวเลือกต่างๆ จะใช้เฉพาะราคาที่ต้องจ่ายในการจัดซื้อครั้งแรกมาเป็นตัววัดเพียงอย่างเดียว ไม่ได้ แต่ต้องพิจารณาถึงค่าใช้จ่ายแอบแฝงอื่นๆ ด้วย และในความเป็นจริงแล้ว เงินที่ต้องจ่ายเป็นค่าซื้อซอฟต์แวร์หรือฮาร์ดแวร์เป็นครั้งแรกนั้น เป็นมูลค่าเพียงแค่ 9-10% ของต้นทุนทั้งหมดเท่านั้น

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

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

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

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

ข้อมูลเพิ่มเติม
http://en.wikipedia.org/wiki/Total_cost_of_ownership