Big Data Architecture #4: สถาปัตยกรรม Data platform บน Public cloud

การออกแบบสถาปัตยกรรม Big Data บน Public cloud อาจแตกต่างกับการออกแบบบนระบบ On-premise ที่ผมเคยเขียนไว้ในตอนที่ 1 ว่าไม่ควรเน้นที่จะเป็น Data warehouse (อ่านเพิ่มเติมได้จาก Big Data Architecture #1: Big Data Pipeline ทำไมไม่ใช่ Data Warehouse) ทั้งนี้เนื่องจากเทคโนโลยี Data Warehouse ไม่ได้เหมาะสมกับคุณลักษณะของ Big Dataในเรื่องของ 4V ทำให้การเก็บข้อมูลขนาดใหญ่จะมีราคาแพง และจะเน้นได้เฉพาะข้อมูลแบบ Structure หรือ Semi-structure

แต่ในกรณีของผู้ให้บริการ Public cloud จะมีบริการ Data Warehouse ทีสามารถรองรับข้อมูลขนาดใหญ่ได้ในราคาที่ถูกกว่า ทำให้ในบางกรณีเราสามารถที่จะออกแบบสถาปัตยกรรม Big Data โดยใช้ Data Warehouse as a Service อย่าง Google BigQuery หรือ Azure Synapse ได้ ดังตัวอย่างในรูปที่ 1

รูปที่ 1 Big data architecture แบบ Data Warehouse only บนระบบ Microsoft Azure

กรณีนี้เราจะเห็นการใช้บริการบน Public Cloud สองอย่างหลักๆคือ

  1. Fully managed ETL service อย่าง Azure Data Factory หรือ Google Cloud DataFusion ที่จะทำหน้าที่ดึงข้อมูลจากแหล่งต่างๆเข่น RDBMS อย่าง MySQL ซึ่งอาจจะอยู่บนระบบ On-Premise หรือ Public Cloud แล้วทำการแปลงข้อมูลให้อยู่ใน Format ที่ต้องการก่อนโหลดเข้า Data Warehouse
  2. Fully managed data warehouse service อย่าง Azure Synapse หรือ Google BigQuery ซึ่งเป็นบริการแบบ PaaS ที่สามารถรองรับการเก็บข้อมูลขนาดใหญ่ โดยผู้ใช้บริการไม่ต้องไปกังวลเรื่องการดูแลระบบ

การใช้สถาปัตยกรรม Big Data ที่เน้นเฉพาะ Data Warehouse จะเหมาะกับกรณีของ Big data ที่มีเฉพาะที่มาจากแหล่งข้อมูลแบบ Relational มีรูปแบบข้อมูล (Schema) ที่แน่นอน ไม่ได้มาจากหลายแหล่งข้อมูลนัก และเน้นเฉพาะการทำ Business Intelligence (BI) หรือต้องการสืบค้นข้อมูลในรูปแบบของ SQL แต่หากมีแหล่งข้อมูลจำนวนมากและมีหลากหลายชนิด รวมถึงต้องการทำการวิเคราะห์เชิง Predictive โดยใช้ Machine Learning เราควรที่จะเน้นสถาปัตยกรรมแบบ Data Platform ที่ใช้ทั้ง Data Lake และ Data Warehouse เหมือนกรณีที่ผมเขียนอธิบายไว้ในตอนที่ 2 (อ่านเพิ่มเติมได้จาก Big Data Architecture #2: สถาปัตยกรรมบน Data Lake) ที่มี Block diagram ดังแสดงในรูปที่ 2

รูปที่ 2 Big data architecture ที่ใช้ทั้ง Data Lake และ Data Warehouse

ในกรณีการออกแบบสถาปัตยกรรมแบบ Data Platform เราจะเห็นการใช้บริการต่างๆบน Public cloud ดังนี้

  1. Fully managed ETL service อย่าง Azure Data Factory, Google Cloud Data Fusion หรือ AWS Glue
  2. Cloud storage อย่าง Azure Data Lake Storage, Google Cloud Storage หรือ AWS S3 เพื่อทำหน้าที่เป็น Storage หลักในการเก็บ Big data
  3. Fully managed data warehouse service อย่าง Azure Synapse, Google BigQuery หรือ AWS Redshift
  4. Fully managed Hadoop/Spark service อย่าง Azure HDInsight, Google DataProc หรือ AWS EMR เพื่อที่จะทำหน้าที่ในการทำ Data preparation หรือการทำ Data Analytics อย่าง Machine Learning โดยใช้เทคโนโลยี Hive หรือ Spark
  5. Ingestion service อย่าง Azure Event Hub, Google Cloud Pub/Sub หรือ AWS Kinesis ที่ทำหน้าที่ในการนำข้อมูลแบบ Streaming เข้าสู่ Cloud Storage

เพื่อให้เห็นสถาปัตยกรรม Big data แบบ Data Platform บน Public cloud services สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS ผมได้วาด Block diagram มาแสดงเปรียบเทียบกับระบบ On-premise ดังรูปที่ 3 – 6

รูปที่ 3 Big data architecture โดยใช้ Hadoop on-premise
รูปที่ 4 Big data architecture แบบ Data Platform บน Azure
รูปที่ 5 Big data architecture แบบ Data Platform บน AWS
รูปที่ 6 Big data architecture แบบ Data Platform บน Google Cloud Platform

ธนชาติ นุ่มนนท์

IMC Institute

Big Data Architecture #3: จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud

ในตอนที่แล้วผมได้ระบุว่าการทำ Big Data ควรที่จะต้องออกแบบสถาปัตยกรรมโดยใช้ Data Lake เป็น Storage หลัก และเทคโนโลยีที่เหมาะกับการทำ Data Lake มากที่สุดก็คือ Hadoop แต่อย่างไรการจะติดตั้งระบบ Hadoop แบบ On-premise ยังมีข้อที่ควรจะพิจารณาอีกในหลายด้านดังนี้

  • ระบบมีค่าใช้จ่ายด้าน Hadware และ Software เริ่มต้นที่ค่อนข้างสูง ซึ่งหากต้องการเก็บข้อมูลเป็นหลักสิบ Terabyte ค่าใช้จ่ายก็อาจเริ่มจากเป็นหลักสิบล้านบาท
  • ระบบ Hadoop มีความซับซ้อนในการติดตั้ง และบำรุงรักษา
  • ระบบ Hadoop จะไม่ได้แยกส่วนที่เป็น Storage และ Processing ออกจากกัน กล่าวคือระบบ Hardware เดียวกันจะถูกนำมาใช้งานในทั้งสองด้าน ทำให้ขาดความยืดหยุ่นและการลงทุนอาจไม่ได้ประสิทธิภาพนัก
  • การจะขยายระบบ Hadoop จะไม่สามารถทำได้ทันทีทันใดเพราะจะมีขั้นตอนในการจัดหา Hardware เพิ่มเติม
  • ระบบ Hadoop มีเทคโนโลยีในการประมวลผลที่ซับซ้อน และมีความหลากหลายทำให้นักพัฒนาต้องเรียนรู้หลากหลายระบบ และแม้แต่เพียงแค่การจะเข้าดูข้อมูลที่เก็บไว้ในระบบก็ไม่ง่ายนัก

จากข้อจำกัดข้างต้นทำให้หลายๆองค์กรหันมาสนใจสถาปัตยกรรม Big data แบบที่ใช้บริการต่างๆของ Public cloud ค่ายดังๆอาทิเช่น Amazon Web Services (AWS), Microsoft Azure หรือ Google Cloud Platform (GCP) เป็นต้น เนื่องจาก Public cloud เหล่านี้มีบริการที่เกี่ยวข้องกับ Big Data มากมาย อาทิเช่น

  • Cloud storage service อย่าง AWS S3, Azure data lake Storage หรือ Google cloud storage
  • Database service อย่าง RDS ของ AWS, Azure SQL หรือ Cloud SQL ของ GCP
  • Data warehouse service อย่าง Redshift ของ AWS, Azure Synapse หรือ Google BigQuery
  • Hadoop/Spark service อย่าง EMR ของ AWS, HDInsight หรือ Databrick ของ Azure, DataProc ของ GCP

ผมได้เขียนสรุปตัวอย่างบริการต่างๆที่ Public cloud ทั้งสามรายนี้มีเมื่อเทียบกับระบบ Big data แบบ On-premise ดังตารางข้างล่างนี้

รูปที่ 1 ตารางเปรียบเทียบบริการบน Public cloud ต่างๆ

จุดเด่นของการออกแบบสถาปัตยกรรม Big Data บน Public cloud เมื่อเทียบกับระบบ On-premise มีดังนี้

  • มีทรัพยากรที่ยืดหยุ่นกว่า (Elastic resources) กล่าวคือบริการต่างๆบน Cloud สามารถจะลดหรือขยายได้อย่างรวดเร็ว เช่นการเพิ่มขนาดการเก็บข้อมูล หรือเพิ่มจำนวน Server
  • Modularity กล่าวคือบริการแต่ละตัวเป็นอิสระต่อกัน ดังนั้นจึงมีการแยกระบบ Storage และ Processing โดยไม่ได้ผูกไว้กับระบบ Hardware ชุดเดียวกันเหมือน Hadoop แบบ On-premise
  • ค่าใช้จ่ายขึ้นอยู่กับการใช้งาน และไม่ต้องเสียค่าลงทุนเริ่มต้นสูงนัก
  • สามารถเริ่มทำโครงการได้อย่างรวดเร็ว เพราะบริการต่างๆบน Public cloud มีอยู่แล้ว สามารถเริ่มต้นโครงการได้ทันที
  • การใช้บริการ Cloud เริ่มเป็น New normal สำหรับการทำระบบไอที และมีบริการใหม่ๆทางด้าน Big data และ AI ที่สามารถทำให้เราสร้างนวัตกรรมในเรื่องต่างๆได้ง่ายขึ้น

แต่การจะใช้บริการบน Public cloud จำเป็นจะต้องออกแบบสถาปัตยกรรมให้ถูกต้องและเลือกบริการให้เหมาะสม ซึ่งผมจะเขียนอธิบายในตอนต่อไป

ธนชาติ นุ่มนนท์

IMC Institute

Big Data Architecture #2: สถาปัตยกรรมบน Data Lake

ในตอนที่แล้ว ผมได้ระบุให้เห็นว่าการออกแบบสถาปัตยกรรม Big Data โดยใช้ Data Warehouse เพียงอย่างเดียวมีความไม่เหมาะสมอย่างไร เลยทำให้ในช่วงปี 2006 ได้มีการนำเทคโนโลยี Apache Hadoop มาใช้ในการทำหน้าเก็บและประมวลผลข้อมูลขนาดใหญ่ ที่เป็นหลักการของ Data Lake แทนที่ระบบของ Data Warehouse โดยมีสถาปัตยกรรมของระบบดังแสดงในรูปที่ 1

รูปที่ 1 Big data architecture โดยใช้ Data Lake

ทั้งนี้ Hadoop ที่เป็น Data Lake จะสามารถตอบโจทย์เรื่อง Big Data ตามคุณสมบัติต่างๆได้ดังนี้

  • Volume เทคโนโลยี Hadoop มีสถาปัตยกรรมแบบกระจายที่ใช้ Commodity Hardware ซึ่งอาจจะเริ่มจากจำนวนเครื่องไม่มากนักและขยายไปเรื่อยๆได้ ทำให้สามารถเก็บข้อมูลได้เป็น Petabyte ในราคาที่ถูกกว่าเทคโนโลยี Data Warehouse มาก
  • Variety เทคโนโลยี Hadoop สามารถเก็บข้อมูลได้หลากหลายชนิดทั้งที่เป็น structured data, semi-structured data และ unstructured data
  • Velocity เทคโนโลยี Hadoop มีการประมวลผลได้หลายภาษา และสามารถที่จะใช้ประมวลผลข้อมูล streaming แบบ real-time หรือ Near real time ได้

นอกจากนี้ Apache Hadoop ยังมีเทคโนโลยีอื่นๆอีกจำนวนมากที่สามารถนำมาใช้งานร่วมกันได้ ทำให้การออกสถาปัตยกรรม Data Lake โดยใช้ Hadoop มีความสมบูรณ์ยิ่งขึ้น โดยเราสามารถที่จะเลือกใช้เทคโนโลยีต่างๆได้ดังนี้

  • Data Ingestion: Sqoop, KafKa, NiFi, Flume, etc.
  • Data Storage: Hadoop Distributed File System (HDFS)
  • Data Processing / Data Analytic: Hive, Spark, Impala, Spark MLlib, etc.
  • Data Visualisation: Tableau, Power BI, Qlik, etc.
รูปที่ 2 Big data architecture ที่ใช้ทั้ง Data Lake และ Data Warehouse

เทคโนโลยีการประมวลผลของ Hadoop อย่าง Hive หรือ Spark หากจะนำไปแสดงผลโดยตรงยัง Data visualisation tool (ดังแสดงในรูปที่ 1) บางครั้งจะพบว่ามีความเร็วไม่พอ ดังนั้นเราจึงมักเห็นสถาปัตยกรรม Big data ที่นำเอา Data Warehouse (หรืออาจเป็น Database) มาเก็บข้อมูลไว้ก่อน (ดังแสดงในรูปที่ 2) เพื่อจะทำให้การทำ Query จาก Data visualisation tool มีความรวดเร็วขึ้น และจะแบ่งวิธีการวิเคราะห์ข้อมูล โดยการทำ BI จะใช้ข้อมูลที่อยู่ใน Data Warehouse ผ่านภาษา SQL ส่วนการทำ Data science ก็จะใช้ข้อมูลใน Data Lake ผ่านเครื่องมือต่างๆเช่น Spark MLlib เป็นต้น

แต่อย่างไรก็ตามการติดตั้ง Hadoop บนระบบ On-premise ก็ยังเป็นการลงทุนที่ค่อนข้างสูง จึงทำให้หลายๆโครงการในปัจจุบันเริ่มพิจารณาสถาปัตยกรรม Big data บนระบบ Cloud ซึ่งผมจะเขียนอธิบายในตอนต่อไป

ธนชาติ นุ่มมนท์

IMC Institute

Big Data Architecture #1: Big Data Pipeline ทำไมไม่ใช่ Data Warehouse

ขั้นตอนการประมวลผลข้อมูลขนาดใหญ่ (Big data pipeline) จะประกอบด้วยขั้นตอนหลักและต้องใช้เทคโนโลยีต่างๆอยู่ 5 ด้านคือ

  1. Data Ingestion คือขั้นตอนการนำข้อมูลดิบ (Raw data) จากแหล่งต่างๆเข้ามา ซึ่งอาจต้องใช้เทคโนโลยีที่แตกต่างกันสำหรับแหล่งข้อมูลหลากหลายชนิด
  2. Data Storage คือขั้นตอนการเก็บข้อมูลมาไว้ที่เดียวกัน ซึ่งเทคโนโลยีในการเก็บข้อมูลจากหลายแหล่งอาจเป็น Data Warehouse หรือ Data Lake
  3. Data Processing คือขั้นตอนในการประมวลผลข้อมูลที่เป็นการแปลงข้อมูลดิบมาอยู่ในรูปแบบของข้อมูลที่นำไปวิเคราะห์ต่อได้ โดยขั้นตอนนี้อาจทำก่อนจะนำเข้า Data storage (เป็นการทำตามหลักการของ ETL) หรืออาจทำหลังจากที่มีข้อมูลอยู่ใน Data Storage แล้วก็ได้ (ทำตามหลักการ ELT) ซึ่งก็จะมีเทคโนโลยีที่หลากหลายในการประมวลผลข้อมูล ขึ้นอยู่กับประเภทของข้อมูลและเทคโนโลยีของ Data storage
  4. Data Analytics คือขั้นตอนการวิเคราะห์ข้อมูล ซึ่งอาจแบ่งได้เป็นการทำ Business Intelligence เพื่อค้นหาตำตอบต่างๆจากข้อมูลทีมีอยู่ หรือการทำ Data science ที่จะนำข้อมูลมาพัฒนาโมเดลในการพยากรณ์ต่างๆ ซึ่งการวิเคราะห์ทั้งสองแบบนี้อาจใช้เทคโนโลยีที่แตกต่างกัน
  5. Data Visualisation คือขั้นตอนในการแสดงผลข้อมูล ซึ่งอาจเป็นการนำข้อมูลที่ได้จากการวิเคราะห์มาแสดงผลให้ผู้ใช้เข้าใจได้ง่ายขึ้นผ่านรายงานหรือรูปกราฟฟิกต่างๆ
รูปที่ 1 Big data pipeline

เมื่อพูดถึงสถาบัตยกรรมทางด้าน Big data หลายคนก็จะมีคำถามในเรื่องของ Data storage ว่าควรจะเป็น Data warehouse หรือ Data Lake ดี เพื่อให้เห็นภาพเปรียบเเทียบระหว่างเทคโนโลยีทั้งสองแบบ ผมของเริ่มจากสถาปัตยกรรมของ Data Warehouse ในรูปที่ 2 ซึ่งเทคโนโลยี Data Warehouse ที่ส่วนใหญ่จะมีพื้นฐานมาจากระบบสถาปัตยกรรมฐานข้อมูลแบบ RDBMS ซึ่งจะทำหน้าที่สองอย่างคืดทั้งในการเป็น Storage และ Analytics โดยใช้ภาษาอย่าง SQL

รูปที่ 2 Data architecture ที่ใช้ Data Warehouse

ซึ่งถ้าเรายกตัวอย่างเทคโนโลยีต่างๆสำหรับการทำ Data Warehouse อาจเห็นดังนี้

  • Data Ingestion: Informatica, Talend, Oracle Data Integration Suite, Pentaho Data integration, Apache NiFi, etc.
  • Data Warehouse (Data storage & Data analytic): HP Vertica, Oracle Exadata, Teradata, etc.
  • Data Analytic (Data science): RapidMiner, Alteryx, Dataiku, etc.
  • Data Visualisation: Tableau, Power BI, Qlik, etc.

แต่เมื่อพิจารณาจากหลักการของ Big data จะพบว่า Data Warehouse มีข้อจำกัดหลายอย่างที่ไม่สามารถตอบโจทย์ได้ดังนี้

  • Volume เทคโนโลยี Data Warehouse จะเก็บข้อมูลปริมาณเพียงเป็นหลัก GB จนถึงเพียงหลายสิบ TB แต่เมื่อพูดถึง Big Data ปริมาณข้อมูลจะมีเป็น TB จนถึง PB ซึ่งถ้าต้องการ Data Warehouse ที่สามารถเก็บข้อมูลขนาดนี้ได้ ราคาจะแพงมากและอาจไม่สามารถรองรับได้
  • Variety เทคโนโลยี Data Warehouse จะออกแบบมาเพื่อรองรับข้อมูลที่มีโครงสร้าง (Structure data) ไม่ได้เน้นข้อมูลหลากหลายชนิด
  • Velocity ข้อมูลขนาดใหญ่บางครั้งจะมีข้อมูลที่เข้ามาต่อเนื่องและอาจต้องการวิเคราะห์ข้อมูลที่เพิ่งถูกนำเข้ามา (Streaming data) แบบทันทีทันใดในลักษณะ Near real time ซึ่งเทคโนโลยี Data warehouse ส่วนใหญ่ไม่ได้ออกแบบมาในลักษณะเพื่องานแบบนี้ และเครื่องมือในการวิเคราะห์ส่วนใหญ่ก็จะเป็นภาษา SQL

นอกจากนี้เราก็อาจจะพบว่า เทคโนโลยี Data Warehouse อาจมีจุดอ่อนอีกบางประการถ้าจะนำมาใช้งานกับ Big Data อาทิเช่น

  • มีราคาค่อนข้างสูง ถ้าต้องการเก็บข้อมูลจำนวนมาก
  • เทคโนโลยีที่ใช้ประมวลผลไม่มีความหลากหลายโดยมากจะใช้ภาษา SQL และหากมาทำงานด้าน Data Science จะค่อยข้างยากสำหรับข้อมูลขนาดใหญ่
  • Data Warehouseจะมีทั้ง Storage และ Analytics/Processing อยู่ในระบบเดียวกัน ทำให้การขยายตัวด้านใดด้านหนึ่งลำบาก เพราะต้องทำควบคู่กันไป

ด้วยเหตุผลเหล่านี้ การทำ Big data จึงจำเป็นต้องใช้ Data Lake เข้ามาทำหน้าที่ Data Storage ซึ่งผมจะอธิบายให้เข้าใจในตอนต่อไป

ธนชาติ นุ่มนนท์

IMC Institute

Data Digital Transformation #13: ระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กร (BDBMMI)

เมื่อวันก่อนผมได้อ่านหนังสือเล่มหนึ่งชื่อ The Economics of Data, Analytics, and Digital Transformation ที่เขียนโดย Kirk Borne และ Bill Schmarzo ซึ่งเพิ่งตีพิมพ์เมื่อปลายปีที่แล้ว ผมว่าเป็นหนังสือที่อธิบายเรื่องเกี่ยวกับการวิเคราะห์คุณค่าของข้อมูลและการทำ Data analytics ในมุมมองทางเศรษฐศาสตร์ได้ดีมาก แต่สิ่งที่ผมอย่างกล่าวถึงในที่นี้คือเรื่องของระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กรหรือ Big Data Business Model Maturity Index (BDBMMI) ที่เขียนไว้ในบทแรกของหนังสือเล่มนี้

BDBMMI ที่กล่าวมานี้อาจไม่ใช่เรื่องใหม่ ผมเองก็เคยนำเรื่องนี้มาเขียนในบทความเรื่อง ระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กร ซึ่งระดับความสามารถของการนำ Big Data ไปใช้ในองค์กร (Big Data Matuarity Model) มีอยู่ 5 ระดับ คือ 1) Business Monitoring 2) Business Insights 3) Business Optimization 4) Data Monetization และ 5) Business Metamorphosis แต่หนังสือเล่มนี้อาจเปลี่ยนชื่อระดับที่ 4 และ 5 เป็น Insights Monetization และ Digital Transformation ตามระดับ โดยได้ให้คำอธิบายแต่ละขั้นตอนที่ชัดเจนขึ้นดังนี้

  1. Business Monitoring ในระดับนี้องค์กรได้ทำ Business Intelligence และ Data Warehouse ซึ่งเป็นขั้นตอนที่เราจะแสดงข้อมูลหรือทำรายงานต่างๆขององค์กรในลักษณะของ Descriptive Analytic ที่เราจะดูข้อมูลในอดีตเพื่อให้ทราบว่า What’s happened? แต่การทำขั้นทำขั้นตอนยังเป็นเพียงการนำข้อมูลมาวัดความสำเร็จที่ผ่านมา และยังขาดการวิเคราะห์สิ่งที่จะเกิดขึ้นหรือการทำ predictive analytics และ prescriptive analytics ที่องค์กรควรจะก้าวไปถึงระดับนี้ให้ได้ เพื่อจะทำให้กลายเป็นองค์กรที่ขับเคลื่อนด้วยข้อมูล ซึ่งจะต้องคิดในการนำข้อมูลมาวิเคราะห์ในเชิงธุรกิจมากขึ้น มีการทำด้าน Data science มากขึ้น และมีการสร้างวัฒนธรรมในการใช้ข้อมูลมากขึ้น
  2. Business Insights ในระดับนี้องค์กรมีการเริ่มต้นตั้งคำถามเพื่อให้ทราบว่า What is likely to happen next? กล่าวคือคาดการณ์ว่าน่าจะเกิดอะไรขึ้นกับ ตลาด กลุ่มลูกค้า สินค้า และบริการต่างๆ เป็นค้นหาข้อมูลเชิงลึก (Insights) ของลูกค้า สินค้า และบริการต่างๆ ขั้นตอนนี้องค์กรจะมีการรวบรวมข้อมูลจากหลายๆแหล่งทั้งภายนอกและภายในองค์กร มีการทำ Data Lake และเห็นการทำงานร่วมกันระหว่างฝั่งธุรกิจแผนกต่างๆ กับทีมงานนักวิทยาศาสตร์ข้อมูลมากขึ้น
  3. Business Optimizationในระดับนี้องค์กรจะมีการทำ predictive analytics และ prescriptive analytics โดยใช้ Machine Learning มากขึ้น จะมีข้อแนะนำในขั้นสิ่งต่างๆทีทำในขั้นตอนปฎิบัติงาน กล่าวคืออาจมี Recommendation system สำหรับลูกค้าแต่ละคน หรือสินค้าในแต่ละอย่าง ซึ่งเป็นผลลัพธ์ที่ได้มาจากการทำ Data science เพื่อคาดการณ์สิ่งที่ดีที่สุดสำหรับองค์กร
  4. Insights Monetization ในระดับนี้ไม่ได้หมายความว่าองค์กรจะนำข้อมูลที่มีอยู่ไปขายเพื่อหารายได้ แต่เป็นการนำข้อมูลไปสร้างคุณค่าเพิ่ม ที่อาจทำให้ได้ช่องทางการตลาดใหม่ๆ กลุ่มลูกค้าใหม่ๆ สินค้าและบริการใหม่ๆ ตลอดจนการหาพันธมิตรทางธุรกิจใหม่ๆ
  5. Digital Transformation ในระดับนี้องค์กรจะมีวัฒนธรรม (Culture) ในการใช้ข้อมูล การวืเคราะห์ข้อมูล เพื่อจะนำมาใช้ให้เกิดประโยชน์ทางธุรกิจอยู่ตลอดเวลา

ในครั้งหน้าผมจะลองมาสรุปให้เห็นว่าการที่จะทำให้องค์กรสามารถเข้าไปสู่ในแต่ละขั้นตอนของ

ธนชาติ นุ่มนนท์

IMC Institute

เราจะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data

เมื่อวันก่อนตอนผมบรรยายในงาน Webinar ครั้งที่ 45 ของสถาบันไอเอ็มซี ในหัวข้อ Data Engineering Technologies & Trends 2021 มีผู้ฟังท่านหนึ่งถามมาว่า “เราจะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data”

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

ผมเองทำงานกับข้อมูลดิบมาเยอะ และบ่อยครั้งก็จะพบว่าข้อมูลจากแหล่งต้นทางผิดจริง แต่ก็ใช่ว่าจะผิดมากมาย ส่วนใหญ่อาจผิดพลาดเพราะการใส่ตัวเลขผิดพลาด หรือมีการเก็บข้อมูลคาดเคลื่อน เรื่องพวกนี้เป็นเรื่องปกติมากของการทำ Data analytics ยิ่งข้อมูลมีขนาดใหญ่ (Big data) ก็อาจทำให้มีโอกาสผิดได้มากขึ้นและจำนวนข้อมูลอาจผิดพลาดมากขึ้น ความผิดพลาดบางครั้งอาจไม่มีนัยสำคัญอะไรเลย แต่บางครั้งข้อมูลที่ผิดพลาดเพียง record เดียวก็อาจทำให้เกิดการวิเคราะห์ผิดพลาดได้ ถ้าความผิดพลาดในข้อมูลนั้นมหาศาล

กระบวนการที่จะช่วยทำให้ลดความผิดพลาดของข้อมูลส่วนหนึ่งคือ การทำ Data preperation ซึ่งเป็นหน้าที่ของ Data engineerในการจะต้องนำข้อมูลดิบ (Raw data) มาแปลง มาตรวจสอบความถูกต้องเสียก่อน เช่นหา Missing data หรือ Outlier กล่าวคือหาข้อมูลที่ดูแล้วผิดปกติแล้วทำการแก้ไข เช่นบางครั้งข้อมูลลบการเงินของบริษัทอาจมีจำนวนสูงผิดปกติ จำนวนพน้กงานมากผิดปกติ ข้อมูลส่วนตัว อายุ น้ำหนัก ดูสูงผิดปกติ หรือข้อมูนำเข้าส่งออกอาจใช้สกุลเงินต่างกัน ข้อมูลเหล่านี้ Data engineer จะช่วยทำการ Data Cleansing ให้ได้ เช่นอาจปรับหาค่าที่เหมาะสมมาใส่ หรือตัดออก และแปลงข้อมูลดิบให้กลายเป็นข้อมูลที่น่าเชื่อถือ (Trusted data) เพื่อให้ Data analyst หรือ Data scientist นำไปทำการวิเคราะห์ข้อมูลและแสดงผลต่อไป

แต่อย่างไรก็ตามแม้ Data engineer จะสร้าง Trusted data ให้แล้ว ก็ใช่ว่าข้อมูลนั้นจะถูกต้อง 100% แหล่งข้อมูลที่เข้ามาก็อาจจะเกิดการผิดพลาดแต่วิธีการด้าน Data engineering ก็ยังไม่สามารถแก้ไขได้ จากสารพัดสาเหตุ อาทิเช่น นำข้อมูลเข้ามาไม่ครบ ได้ข้อมูลผิดๆแต่ต้น หรือแม้แต่ข้อมูลถูกต้องแล้ว แต่ Data analyst ไม่เข้าใจข้อมูลดีพอ เลยทำการวิเคราะห์ที่ผิดแล้วแสดงผลผิดพลาดก็เป็นไปได้

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

ดังนั้นการที่จะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data คำตอบผมคือ กระบวนงานของ Data engineering และประสบการณ์ของ Domain expert เป็นเรื่องสำคัญสุด

ธนชาติ นุ่มนนท์

IMC Institute

งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 2)

ที่มา https://www.kdnuggets.com/2021/04/consider-being-data-engineer-instead-data-scientist.html?fbclid=IwAR04yQ7C9XjIgXJERZLSofSA3veL94Lzp12nAJL_FsjytztgWo8-axZbfWA

เมื่อตอนที่แล้วผมเขียนถึงประเภทงานด้านต่างๆที่เกี่ยวข้องกับการวิเคราะห์และบริหารจัดการข้อมูล (งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 1)) และชี้ให้เห็นว่างานของวิศวกรข้อมูล (Data emgineer) มีความสำคัญพอๆกับงานของนักวิทยาศาสตร์ข้อมูล (Data Scientist) และบางครั้งอาจมีความสำคัญมากกว่าเสียด้วยซ้ำไป

สำหรับเหตุผลต่างๆขออธิบายดังนี้

  1. การทำงานด้านข้อมูลจะเริ่มต้นจากกระบวนการทางวิศวกรรมข้อมูล ซึ่งเป็นหน้าที่ของ Data engineer ที่จะต้องนำเข้าข้อมูล จัดการแปลงข้อมูล ปรับข้อมูลให้มีความถูกต้อง รวมถึงการตัดข้อมูลที่ผิดพลาดออก ก่อนที่จะส่งงานนี้ไปให้ Data Scientist หรือ Data analyst ไปทำการพยากรณ์หรือวิเคราะห์ข้อมูลต่อ ดังนั้นถ้าวิศวกรข้อมูลส่งข้อมูลมาผิดพลาด ไม่สมบูรณ์ ก็จะมีผลทำให้การวิเคราะห์หรือการพยากรณ์ข้อมูลต่างๆผิดพลาดไปด้วย ดังที่กล่าวว่า garbage in garbage out
  2. เมื่อวิเคราะห์ถึง Data analytic life cycle ตามมาตรฐานของ CRISP-DM(Cross-industry standard process for data mining) จะเห็นได้ว่ามีอยู่ 6 ขั้นตอน เริ่มจาก การทำความเข้าใจธุรกิจ (Business Understanding) ไปจนถึงการนำไปใช้งาน (deployment) ซึ่งเราจะพบว่างานส่วนใหญ่เกือบ 70-80% จะใช้เวลาไปกับขั้นตอนของ Data preparation กล่าวคือการเตรียมข้อมูลที่เป็นงานของ Data engineer ขณะที่งานของ Data scientist อย่างขั้นตอนการสร้างแบบจำลอง (Modeling) และ การประเมินผล (Evaluation) จะใช้เวลาไม่นานนัก
  1. งานการวิเคราะห์ข้อมูลขนาดใหญ่ (Big data)ที่พบในทางปฎิบัติจริงโดยมากจะเป็นงานการวิเคราะห์ข้อมูลทั่วไปที่ใช้หลักการของ Business Intelligence (BI) โดยเป็นหน้าที่ของนักวิเคราะห์ด้านข้อมูล (Data analyst) แล้วอาจนำผลไปทำ Dashboard โดยใช้เครื่องมือด้าน Visualization ซึ่งงานเหล่านั้นพบมากกว่างานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ต้องทำโดย Data scientist ด้วยซ้ำไป เพราะหน่วยงานต่างๆจะเริ่มต้นจากการทำ BI ก่อน
  2. งานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ทำโดยมากมักจะเป็นงานในการพัฒนาโมเดลพื้นฐานที่มีอยู่ทั่วไป และอาจต้องการนักวิทยาศาสตร์ข้อมูลที่เน้นการพัฒนาโปรแกรม หรือ Citizen Data Scientist ในการทำมากกว่าต้องการ นักวิทยาศาสตร์ข้อมูลขั้นสูง ซึ่งเราจะพบว่าสามารถนำงานเหล่านั้นให้ Data engineer มาศึกษาการเขียนโปรแกรมการพยากรณ์ข้อมูลได้ และบางครั้งอาจจะง่ายกว่าการที่จะเอานักวิทยาศาสตร์ข้อมูลขั้นสูงมาฝึกเป็น Data engineer เสียด้วยซ้ำไป กล่าวคือเราอาจให้ Data engineer มาทำหน้าที่ Data scientist ได้ในงานที่ไม่ซับซ้อน
  3. ข้อมูลจาก The 2021 Data Science Interview Report ระบุว่าตำแหน่งงานทางด้าน Data scientist เริ่มมีการเติบโตน้อยลงจากที่เคยเพิ่มปีละ 80% เหลือเพียงโตขึ้น 10% จากปี 2020 เมื่อเทียบกับปี 2019 ขณะที่งานด้าน Data engineer กลับโตขึ้นถึง 40% นอกจากนี้ยังมีการศึกษาโดย Mihail Eric ที่ลงบทความใน https://www.kdnuggets.com/ พบว่างานทางด้าน Data engineer มีความต้องการสูงกว่างานด้าน Data science ถึง 70%
  1. สุดท้ายมีบทความเรื่อง Data Engineer VS Data Scientist ที่รายงานการสำรวจเงินเดือนเฉลี่ยระหว่าง Data engineer กับ Data Scientist ในปี 2018 พบว่าเงินเดือนของ Data engineer เฉลี่ยอยู่ที่  $151K ต่อปี ส่วน Data Scientist $139K ต่อปี
ที่มา https://towardsdatascience.com/data-engineer-vs-data-scientist-bc8dab5ac124
ที่มา ที่มา https://towardsdatascience.com/data-engineer-vs-data-scientist-bc8dab5ac124

ทั้งหมดนี้คือสิ่งทีอยากชี้ให้เห็นว่างานของวิศวกรข้อมูล (Data engineer) มีความสำคัญมากและอาจเป็นหนึ่งในอาชีพที่น่าสนใจที่สุดสำหรับคนที่ต้องการทำงานด้านข้อมูล

ธนชาติ นุ่มมนท์

IMC Institute

งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 1)

อาชีพนักวิทยาศาสตร์ข้อมูล (Data Scientist) เป็นอาชีพที่กล่าวขานกันมากที่สุด คนหลายคนอยากทำงานอาชีพนี้ เยาวชนรุ่นใหม่ได้รับการบอกกล่าวว่าเป็นอาชีพที่น่าจะมีอนาคตที่ดี สถาบันการศึกษาในบ้านเราหลายที่ก็เปิดสาขาด้าน Data Science ในระดับปริญญาตรีขึ้นมา

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

  • วิศวกรข้อมูล (Data engineer) คือผู้ที่จะนำข้อมูลเข้าระบบ ทำการแปลงข้อมูล ทำเรื่อง Data Cleansing ทำให้ข้อมูลมีความถูกต้องขึ้น ซึ่งงานตรงส่วนนี้ต้องมีความรู้ด้านไอที การพัฒนาโปรแกรมภาษาต่างๆเช่น Python และเทคโนโลยีด้านข้อมูล โดยเฉพาะเรื่องของ Big Data อาทิเช่น Database, Hadoop, Spark และ Cloud services ต่างๆ
  • นักวิเคราะห์ด้านข้อมูล (Data analyst) หรือคนที่จะนำข้อมูลที่ผ่านขบวนการของ Data engineering มาแล้วมาวิเคราะห์ทางธุรกิจในอุตสาหกรรมนั้นๆ แล้วอาจนำไปแสดงผลต่อ ซึ่งงานตรงส่วนนี้นอกจากต้องมีความรู้ด้านธุรกิจนั้น อาจมีความสามารถในการใช้ภาษาคอมพิวเตอร์ที่จะสอบถามข้อมูลอย่าง SQL และอาจต้องสามารถใช้เครื่องมือพวก Data visualisation ได้
  • นักวิทยาศาสตร์ข้อมูล (Data Scientist) คือผู้ที่จะนำข้อมูลที่ผ่านขบวนการของ Data engineering มาแล้ว มาทำการพัฒนาโมเดล พยากรณ์ในเรื่องต่างๆ โดยใช้หลักการของ Machine Learning, AI หรือ Deep learning ผู้ที่จะทำงานด้านนี้ต้องมีความรู้ทางด้านคณิตศาสตร์ การเขียนโปรแกรม และความรู้เชิงธุรกิจนั้นได้ดี แต่ด้วยงานพยากรณ์ข้อมูลมีหลากหลายและเครื่องมือเริ่มง่ายขึ้น ทำให้เราอาจแบ่งนักวิทยาศาสตร์ข้อมูลนี้ได้เป็นกลุ่มย่อยต่างๆดังนี้
    • นักวิทยาศาสตร์ข้อมูลขั้นสูง คือคนที่มีความรู้ด้านคณิตศาสตร์ อัลกอริทึมต่างๆเป็นอย่างดี และจะมาพัฒนาโมเดลในการพยากรณ์ในเรื่องใหม่ๆหรือต้องเจาะลึก และยากกว่าที่เป็นปัญหาโดยทั่วไป ทีมีโมเดลและ Library มาตรฐานอยู่
    • นักวิทยาศาสตร์ข้อมูลที่เน้นการพัฒนาโปรแกรม คนกลุ่มนี้อาจแปรผันมาจาก วิศวกรข้อมูล แต่จะเน้นการเขียนโปรแกรมจากเครื่องมือ หรือ Library ต่างๆที่มีอยู่ เช่นการเขียนภาษา Python หรือ R เพื่อใช้ Scikit-Learn หรือ TensorFlow คนกลุ่มเหล่านี้อาจไม่ได้เก่งโมเดลทางคณิตศาสตร์นัก ทำให้ไม่สามารถทีจะทำการพยากรณ์ในเรื่องยากๆ ที่ต้องมีความรู้ด้านโมเดลเป็นอย่างดี และถ้าในอนาคตเครื่องมือง่ายๆขึ้นไปเรื่อยๆงานของกลุ่มคนเหล่านี้ ก็จะมีความสำคัญน้อยลง เพราะสามารถใช้คนกลุ่มที่สามทำงานได้ดีกว่า
    • Citizen Data Scientist เนื่องจากเครื่องมือในการทำวิทยาศาสตร์ข้อมูลในปัจจุบันเริ่มง่ายขึ้นมาก จนบางครั้งคนทั่วไปก็สามารถทำได้ เช่นการใช้เครื่องมืออย่าง AutoML ดังนั้นคนกลุ่มนี้ในอนาคตจะเป็นกลุ่มใหญ่ในการพยากรณ์ข้อมูล โดยเน้นที่มีความรู้เชิงธุรกิจหรืออุตสาหกรรมนั้น เข้าใจโจทย์ได้ลึกซึ้งกว่าสองกลุ่มแรก จะทำให้มีความต้องการคนในกลุ่มนี้มากขึ้น โดยเอาคนที่มีความรู้ในธุรกิจนั้นไปเรียนรู้การใช้เครื่องมือ เช่นนักเศษฐศาสตร์ นักวิชาการเกษตร แพทย์ นักการตลาด เป็นต้น
  • ผู้ดูแลระบบ (Data administrator) การวิเคราะห์ข้อมูลจำเป็นต้องมีระบบโครงสร้างพื้นฐานด้านไอที จึงต้องมีคนที่มีความสามารถที่จะติดตั้งและดูแล Server หรือ Middleware ต่างๆเช่น Database, Data warehouse หรือ Hadoop ซึ่งงานตรงส่วนนี้ต้องมีความรู้ด้านไอที โดยเฉพาะในเชิงของระบบปฎิบัติการต่างๆ

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

สิ่งที่สำคัญอีกอย่างที่เห็นจากรูปคืองานด้านข้อมูลส่วนใหญ่ จะเริ่มต้นจากขบวนการ Data Engineering และเผลอๆมากกว่า 70-80% ของงาน จะเป็นงานของวิศวกรข้อมูล อย่างที่เรารู้กันดีครับ ถ้าข้อมูลถูกต้องการวิเคราะห์ต่างๆก็จะถูกต้องตาม หรือที่เรามักพูดว่า “garbage in garbage out”

เดี๋ยวในตอนหน้า ผมจะมาเขียนสรุปให้ต่อว่า ทำไมงาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist หรือบางครั้งอาจสำคัญกว่าด้วยซ้ำไป

ธนชาติ นุ่มนนท์

IMC Institute

Data Digital Transformation #12: ข้อแนะนำ 10 ข้อเรื่องการทำกลยุทธ์ด้านข้อมูล

ผมเขียนเรื่องการทำกลยุทธ์ด้านข้อมูล (Data Strategy) ขององค์กรมาหลายตอน และเน้นว่าองค์กรจำเป็นอย่างยิ่งที่จะต้องทำกลยุทธ์ด้านนี้เพื่อจะนำไปสู่เรื่องของการทำ Digital Transformation โดยมีบทความหลายๆตอนที่เกี่ยวข้องคือ

และเพื่อให้การทำกลยุทธ์เป็นไปได้ดี ผมขอนำข้อแนะนำที่สำคัญของ ของ CDQ Competence Center ที่อยู่ 10 ข้อมาเขียนสรุปให้ดังนี้

  1. การทำ Data strategyให้ประสบความสำเร็จได้นั้น ผู้บริหารสูงสุดขององค์กรจะต้องเป็นเจ้าภาพหรือให้การสนับสนุนอย่างเต็มที่
  2. องค์กรจะต้องกำหนดให้การทำ Data strategy เป็นวาระที่สำคัญอย่างยิ่งขององค์กร
  3. การจัดทำ Data strategy จะต้องเป็นความร่วมมือกันระหว่างผู้เชี่ยวชาญด้านข้อมูล (เช่นนักวิเคราะห์ข้อมูล หรือนักวิทยาศาสตร์ข้อมูล) ทีมงานไอที และทีมงานด้านธุรกิจแผนกต่างๆ
  4. การจัดทำ Data strategy ควรจะเริ่มต้นจากการกำหนดลำดับความสำคัญของ Data use cases ต่างๆที่ชัดเจน
  5. การจัดทำ Data strategy จำเป็นอย่างยิ่งที่จะต้องสอดคล้องกับกลยุทธ์ด้านต่างๆขององค์กร
  6. การจัดทำ Data strategy อาจทำได้โดยใช้ template อย่าง Data Strategy Canvas ที่มีองค์กรประกอบอยู่ 7 ด้านคือ 1) Need for action 2) Vision 3) Mission and scope 4) Business value 5) Key capabilities 6) Code of conduct และ 7) Transformation
  7. Data Strategy ที่ดีควรจะตอบคำถามขององค์กรหลักๆในสองด้านคือ ด้าน Data Monetisation และ ด้าน Data Foundation
  8. ควรจะต้องสื่อสาร Data Strategy ขององค์กรให้กับพนักงานทุกระดับรับทราบ
  9. ตัวชี้วัดของ Data Strategy จะต้องมีความชัดเจน สามารถติดตาม และทำการประเมินได้
  10. ควรจะมีการทบทวน Data Strategy เป็นประจำ โดยอาจต้องมีแผนปรับปรุงทุกระยะ 1-3 ปี

ธนชาติ นุ่มนนท์

IMC Institute

Data Digital Transformation #11: แบบประเมิน Data Maturity ขององค์กรแบบออนไลน์

ในตอนที่แล้วผมบอกไว้ว่า องค์กรควรทำการประเมินความพร้อมทางด้านข้อมูล (Data matuarity assessment) ขององค์กรให้ได้ก่อน และตั้งใจจะทำแบบประเมินออนไลน์มาให้ได้ทดสอบกัน ตอนนี้ผมได้ทำแบบประเมินเสร็จแล้ว โดยผู้ที่สนใจต้องการจะไปทำการประเมินความพร้อมด้วยตัวเองสามารถเข้าไป https://tinyurl.com/datamatuarity

ทั้งนี้ในแบบประเมินออนไลน์นี้ จะมีคำถามทั้งหมด 32 ข้อ โดยแบ่งเป็นด้านต่างๆดังนี้

  • ความตระหนักและวัฒนธรรม (Awareness and Culture) 5 ข้อ
  • การใช้งานข้อมูล (Data Usage) 8 ข้อ
  • ภาวะผู้นำขององค์กร (Leadership) 5 ข้อ
  • เครื่องมือและเทคโนโลยี (Tools and Technology) 5 ข้อ
  • ทักษะ (Skills) 4 ข้อ
  • ธรรมาภิบาลข้อมูล (Governance) 5 ข้อ

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

สำหรับผู้ที่สนใจเรื่องของ Data Digital Transformation เพิ่มเติม ผมกำลังจะเปิดหลักสูตรที่เรียนออนไลน์ 6 ครั้งเริ่มในเดือนกรกฎาคม และมีการให้คำปรึกษาแบบ One on One ออนไลน์อีกหนึ่งชั่วโมงหลังการอบรม ผู้สนใจสามารถเข้าไปดูข้อมูลเพิ่มเติมได้ที่ https://bit.ly/3etl1iV

ธนชาติ นุ่มนนท์

IMC Institute