BzInsight

ภาพจาก 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 ก็ได้

เมื่อกูเกิลลงมือทำเว็บเบราว์เซอร์ที่ชื่อ Chrome เพียงไม่กี่วันก็สร้างความฮือฮาไปทั่วโลก เห็นแว็บๆ ว่า Google Analytics วัดส่วนแบ่งการตลาดของผู้ใช้ Chrome ได้สูงถึง 6 เปอร์เซ็นต์แล้ว หลังจากเปิดตัวไปได้แค่ไม่กี่วัน จริงหรือโม้ผมไม่ทราบ รู้แต่เพียงว่ามันเป็น talk of the town เวลานี้สำหรับโลกไอที

ภาพจาก SiliconRepublic.com

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

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

ฝากถึงผู้ว่าจ้างทำเว็บทั้งหลายด้วยนะครับ อย่ามัวแต่มองแค่ว่าเว็บมันทำงานได้บน IE แต่ให้ดูด้วยว่า สามารถทำงานในหลากหลายแพลตฟอร์มได้หรือไม่ เรื่องนี้ส่งผลไม่เฉพาะกับตัวเว็บเท่านั้น แต่องค์ประกอบอื่นๆ ด้วยเช่นกันอาทิเช่น Plug-in หรือ Theme ต่างๆ

คิดต่อไปอีกเกี่ยวกับเรื่องการใช้งาน Business Intelligence ในองค์กร ผมมองเห็นรูปแบบที่ไม่แตกต่างกันมากนัก ในแต่ละบริษัทลูก หรือแต่ละแผนก หลายครั้งที่ต่อต้าน standard system หรือ corporate solution ซึ่งมักจะเป็นระบบมาตรฐานขนาดใหญ่ ออกแบบมาเพื่อรองรับการเติบโตในอนาคต ให้ความสำคัญกับ scalability แืละ reliability ส่งผลให้ระบบเหล่านี้มีค่าใช้จ่ายสูง ใช้เวลานานในการพัฒนาและ implement ในแต่ละแผนกหรือแต่ละบริษัทย่อย

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

แล้ววันร้ายคืนร้ายก็มาเยือน เหมือนกับวันที่ Google ออก Chrome มา บริษัทของคุณอาจจะประกาศซื้อกิจการบริษัทอื่น ต้องมีการ integrate ระบบคอมพิวเตอร์อย่างเร่งด่วน หรือไม่ก็ออกมาผลักดันให้ทุกหน่วยงานในองค์กรใช้ระบบ CRM แบบเดียวกันเพื่อลดต้นทุน ทีนี้ละคุณเอ๋ย คนที่จะได้ประโยชน์ก่อน คือคนที่ใช้ standard system เพราะนี่คือส่วนที่จะได้รับการดูแลก่อน integration จะเริ่มจากส่วนนี้ก่อน การสร้างอินเทอร์เฟสไปยังระบบงานใหม่ๆ ก็จะเริ่มจาก standard system ก่อน ปล่อยให้คนที่ใช้ customize หรือ local system ก็ต้องดิ้นรนกันเองต่อไป