EP03 มีไดอะแกรม

เข้าใจระบบสารสนเทศในมุมองค์กร

Information Systems (IS)

7 นาที·9 หัวข้อ
ตอนนี้เจาะ "ระบบสารสนเทศ" ในมุมที่ DCE ต้องใช้คุยกับลูกค้าองค์กร ไม่ใช่ทฤษฎีวิชาการ โทนพี่ติวน้อง ความยาว 14–18 นาที ศัพท์เทคนิคอังกฤษ อธิบายไทย

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

ระบบสารสนเทศไม่ได้มีแค่เทคโนโลยี แต่ประกอบด้วยห้าส่วนที่ทำงานร่วมกัน: people (คนใช้และคนดูแล), process (ขั้นตอนการทำงานและกฎธุรกิจ), data (ข้อมูล), technology (hardware, software, network) และ ในมุมองค์กรบางตำราเพิ่ม governance หรือ policy เข้าไป จุดสำคัญที่ DCE ต้องเข้าใจคือเทคโนโลยีเป็นเพียงหนึ่งในห้า การย้ายขึ้นคลาวด์ที่สำเร็จต้องคำนึงถึงคนและกระบวนการด้วย ไม่ใช่แค่ย้าย server เพราะถ้าทีมไม่มีทักษะหรือกระบวนการไม่รองรับ โครงการก็ล้มได้แม้เทคโนโลยีจะดี

นี่คือแนวคิดที่ DCE ใช้บ่อยที่สุดเวลาฟังลูกค้าเล่าระบบ ระบบในองค์กรแบ่งหยาบ ๆ เป็นสองกลุ่ม:

OLTP (Online Transaction Processing): ระบบที่รองรับงานประจำวัน เน้นการเขียนอ่านข้อมูลทีละรายการเล็ก ๆ จำนวนมากและต้องเร็วและถูกต้อง เช่นระบบสั่งซื้อ ระบบธนาคาร ระบบจองตั๋ว ลักษณะคือ transaction สั้น ต้องการ ACID และ low latency ฐานข้อมูลที่เหมาะคือ relational แบบ normalized

OLAP (Online Analytical Processing): ระบบที่เน้นการวิเคราะห์และรายงาน อ่านข้อมูลปริมาณมหาศาลเพื่อสรุปแนวโน้ม เช่น dashboard ยอดขาย การวิเคราะห์พฤติกรรมลูกค้า ลักษณะคือ query ซับซ้อน อ่านข้อมูลย้อนหลังเยอะ ไม่เน้นเขียนบ่อย โครงสร้างข้อมูลมักเป็น denormalized แบบ star schema ฐานข้อมูลที่เหมาะคือ data warehouse

ทำไมเส้นนี้สำคัญ: เพราะมันชี้ทันทีว่าควร map ระบบลูกค้าไป service ไหนบน GCP ระบบ OLTP ไปทาง Cloud SQL, Cloud Spanner, AlloyDB ส่วน OLAP ไปทาง BigQuery DCE ที่ฟังลูกค้าแล้วแยก OLTP กับ OLAP ออกทันทีจะออกแบบได้ตรงจุด

OLTP vs OLAP

OLTP

Online Transaction Processing

  • งานประจำวัน เขียน/อ่านทีละรายการเล็ก ๆ จำนวนมาก
  • ต้องเร็วและถูกต้อง — transaction สั้น ต้องการ ACID, low latency
  • โครงสร้าง relational แบบ normalized
  • ตัวอย่าง: ระบบสั่งซื้อ ธนาคาร จองตั๋ว
  • GCP: Cloud SQL, Cloud Spanner, AlloyDB

OLAP

Online Analytical Processing

  • วิเคราะห์และรายงาน อ่านข้อมูลมหาศาลเพื่อสรุปแนวโน้ม
  • query ซับซ้อน อ่านย้อนหลังเยอะ ไม่เน้นเขียนบ่อย
  • โครงสร้าง denormalized แบบ star schema
  • ตัวอย่าง: dashboard ยอดขาย วิเคราะห์พฤติกรรมลูกค้า
  • GCP: BigQuery (data warehouse)
เส้นแบ่งที่ DCE ใช้บ่อยที่สุด: ฟังลูกค้าเล่าระบบแล้วแยกให้ออกว่าเป็นงานธุรกรรมประจำวัน (OLTP) หรือการวิเคราะห์ (OLAP) เพื่อ map ไป service ให้ถูก

ควรรู้จักชื่อและบทบาทของระบบเหล่านี้เพราะลูกค้าจะพูดถึง:

  • ERP (Enterprise Resource Planning): ระบบรวมศูนย์บริหารทรัพยากรองค์กร เช่น SAP, Oracle จัดการการเงิน คลัง การผลิต มักเป็น OLTP ที่สำคัญมากและย้ายยาก
  • CRM (Customer Relationship Management): ระบบบริหารความสัมพันธ์ลูกค้า เช่น Salesforce
  • Data Warehouse / BI: ระบบวิเคราะห์และรายงาน
  • Legacy systems: ระบบเก่าที่อาจรันบน mainframe หรือเทคโนโลยีล้าสมัย เป็นโจทย์ migration ที่ท้าทาย
  • Middleware และ integration layer: ตัวเชื่อมระบบต่าง ๆ เข้าด้วยกัน เช่น message queue, API gateway, ESB

ข้อมูลในองค์กรมักไหลตามเส้นทางนี้: source systems (ระบบต้นทางที่สร้างข้อมูล เช่น ERP, แอป, IoT) แล้ว ingestion (ดึงข้อมูลเข้ามา ทั้งแบบ batch และ streaming) แล้ว storage (เก็บใน data lake หรือ warehouse) แล้ว processing/transformation (แปลงและทำความสะอาดข้อมูล) แล้ว analytics/serving (วิเคราะห์ ทำ dashboard ป้อนโมเดล ML) แล้วสุดท้ายคือ decision (คนหรือระบบนำไปตัดสินใจ) การเข้าใจ flow นี้ทำให้ DCE มองเห็นว่าจะวาง service GCP ตรงไหนในห่วงโซ่ และจุดไหนเป็นคอขวดหรือความเสี่ยงของลูกค้า

Enterprise Data Flow
ข้อมูลในองค์กรไหลจากต้นทางถึงการตัดสินใจ DCE ต้องมองเห็นว่าจะวาง service GCP ตรงไหนในห่วงโซ่ และจุดไหนเป็นคอขวด

อีกเส้นแบ่งที่ควรเข้าใจ: structured data คือข้อมูลมีโครงสร้างชัดอยู่ในตาราง เช่นข้อมูลธุรกรรม; semi-structured คือมีโครงสร้างหลวม เช่น JSON, XML, log; unstructured คือไม่มีโครงสร้างตายตัว เช่นข้อความ รูป วิดีโอ เสียง ปัจจุบันข้อมูล unstructured โตเร็วมากและเป็นวัตถุดิบสำคัญของงาน AI การเข้าใจประเภทข้อมูลช่วยเลือกที่เก็บและเครื่องมือประมวลผลที่เหมาะ ซึ่งจะลงลึกในตอน storage และ data warehouse

ถาม: "อธิบายความต่างของ OLTP กับ OLAP" ตอบ: OLTP เน้น transaction ประจำวันเร็วและถูกต้อง ใช้ relational; OLAP เน้นวิเคราะห์ข้อมูลย้อนหลังปริมาณมาก ใช้ data warehouse พร้อมยกตัวอย่างและ map ไป Cloud SQL กับ BigQuery

ถาม: "ลูกค้ามี ERP บน on-prem อยากทำ analytics ยอดขาย จะออกแบบ flow อย่างไร" ตอบ: ดึงข้อมูลจาก ERP (source/OLTP) ผ่าน ingestion มาเก็บและวิเคราะห์ใน BigQuery (OLAP) โดยไม่กระทบระบบ transaction หลัก แล้วต่อ BI tool ทำ dashboard

ถาม: "ทำไมไม่ควรรัน analytics หนัก ๆ บน database transaction โดยตรง" ตอบ: เพราะ query วิเคราะห์ที่อ่านข้อมูลเยอะจะแย่งทรัพยากรและทำให้ระบบ transaction ช้าหรือล่ม จึงควรแยก OLAP ออกมาที่ data warehouse

มอง IS เป็นแค่เทคโนโลยี ลืมเรื่องคนและกระบวนการ; แยก OLTP กับ OLAP ไม่ออกทำให้ map service ผิด; ไม่เข้าใจว่าระบบองค์กรเชื่อมกันอย่างไรจึงออกแบบ integration ไม่ได้; มองข้าม legacy system ที่เป็นข้อจำกัดจริงของลูกค้า; ไม่สนใจ data flow ทำให้เสนอ service เป็นจุด ๆ แทนที่จะเป็นภาพรวม

IS ประกอบด้วยคน กระบวนการ ข้อมูล และเทคโนโลยี เทคโนโลยีเป็นแค่ส่วนเดียว เส้นแบ่งที่สำคัญที่สุดคือ OLTP กับ OLAP ซึ่งชี้ว่าควร map ไป service ไหนบน GCP รู้จักระบบองค์กรหลักอย่าง ERP และ CRM เข้าใจ data flow ตั้งแต่ source ถึง decision และแยกประเภทข้อมูล structured กับ unstructured ได้ ทั้งหมดนี้คือพื้นฐานที่ทำให้ออกแบบโซลูชันที่ทำงานกับของเดิมของลูกค้าได้จริง