ทำไมแดชบอร์ดแบบบริการตนเองถึงใช้ไม่ได้ผล

• "self-serve dashboards" ในความเป็นจริงมักใช้ไม่ได้ผล เพราะวิศวกรหรือ data scientist ต้องใช้เวลามากในการเขียนคิวรีและเตรียมแดชบอร์ดให้ผู้ใช้ฝั่งธุรกิจ

ทำไม "self-serve BI" ถึงใช้ไม่ได้ผล

• SQL คือเครื่องมือ "self-serve BI" เพียงตัวเดียว แต่ผู้ให้บริการ "self-serve BI" ส่วนใหญ่มักพยายามอำพราง SQL ให้ดูเหมือนเป็นอย่างอื่น
• การเขียน SQL query ไม่ใช่อุปสรรคเดียวที่ทำให้ผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจไม่สามารถคิวรีข้อมูลได้ พวกเขายังไม่เข้าใจความหมาย แหล่งที่มา และวิธีการคำนวณของข้อมูล รวมถึงไม่รู้วิธีตีความและตรวจสอบผลลัพธ์

ความพยายามครั้งที่ 1: แนวทางแบบ "dropdown และ checkbox" เดิม ๆ

• อินเทอร์เฟซนี้เป็นเพียงความพยายามทำ "SQL-by-mouse" เท่านั้น ไม่ได้ดีกว่า SQL และกลับช้ากว่า ไม่น่าเชื่อถือกว่า มีข้อจำกัดมากกว่า และไม่สามารถนำไปใช้กับเครื่องมืออื่นแบบทั่วไปได้
• คนอย่าง CFO จะไม่ใช้อินเทอร์เฟซนี้เพื่อคิวรีข้อมูล เพราะพวกเขาไม่มีบริบทที่ช่วยให้เข้าใจข้อมูล และไม่มั่นใจในผลลัพธ์ที่ได้

ความพยายามครั้งที่ 2: แนวทาง text-to-SQL

• LLM มีประสิทธิภาพในการแปลภาษาธรรมชาติเป็น SQL มากเสียจนเกือบจะดีเกินไป แม้คำถามจะไม่เหมาะสม มันก็ยังพยายามสร้างคิวรีออกมา
• คนสายเทคนิคจะสังเกตได้ว่าคำถามนั้นยังไม่เหมาะสม และจะขอข้อมูลบริบทเพิ่มเติม อธิบายประเภทข้อมูลที่มีอยู่ และร่วมมือกับทีมธุรกิจเพื่อทำให้คำถามมีความแม่นยำและใช้งานได้จริง
• LLM อาจกลายเป็นโซลูชันที่แท้จริงของ "self-serve BI" ได้ แต่ยังไม่ใช่ในรูปแบบปัจจุบัน มันต้องการบริบทมากกว่านี้ และต้องเก่งขึ้นในการแสดงความไม่แน่นอนและขอข้อมูลเพิ่มเติม

สิ่งที่ได้ผลจริง

• ปัญหาของ "self-serve BI" ไม่ใช่เรื่อง SQL แต่เป็นเรื่องบริบทและความหมายของข้อมูล ทางแก้คือการสอนให้ผู้คนเข้าใจข้อมูลที่พวกเขากำลังคิวรี ไม่ว่าอินเทอร์เฟซจะเป็นแบบใดก็ตาม
• การให้ทีมเทคนิคบันทึกองค์ความรู้ทั้งหมดเป็นเอกสารก่อให้เกิดภาระงานเพิ่มมาก และเอกสารก็ล้าสมัยอย่างรวดเร็ว
• ทางออกที่แท้จริงของ "self-serve BI" ไม่ใช่การทำให้ BI เป็น "self-serve" สำหรับคนที่ไม่ใช่สายเทคนิค แต่เป็นการให้คนสายเทคนิคมีเครื่องมือที่ดีกว่าเพื่อสนับสนุนผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจได้อย่างมีประสิทธิภาพยิ่งขึ้น

ข้อเสนอเกี่ยวกับเครื่องมือที่ดีกว่า:

1. ให้ LLM กับคนสายเทคนิค ไม่ใช่ผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจ
2. เปิดให้ใช้เครื่องมือที่ถนัดอย่างอิสระ เช่น Python, R เป็นต้น เพื่อจัดการข้อมูลได้อย่างยืดหยุ่น
3. ทำให้คนสายเทคนิคแชร์สิ่งที่ทำได้ง่ายขึ้น เพราะ notebook และแอปพลิเคชันข้อมูลภายในมักแชร์ได้ยาก เนื่องจากต้องจัดการกับ container, dependency และ infrastructure

[GN⁺]

ความคิดเห็นจาก Hacker News

• ที่บริษัทหนึ่งซึ่งทำแดชบอร์ดด้วยเครื่องมือ BI มีคนสังเกตว่าตัวเลขดูแปลก ๆ เลยไปเปิดดูตัวสร้างคิวรี แต่กลับไม่มีทางรู้เลยว่าบางส่วนของคิวรีเป็น inner join หรือ left join
  แม้แต่นักวิเคราะห์ธุรกิจที่สร้างแดชบอร์ดนั้นก็ไม่รู้ ทั้งที่จริง ๆ ตั้งใจให้เป็น inner join แต่ตอนรันกลับใช้ left join ทำให้ข้อมูลที่แสดงออกมาสูงกว่าความเป็นจริงถึงหนึ่งหลัก
  ตั้งแต่นั้นมาก็เลิกเชื่อชั้นนามธรรมแบบนี้ที่ครอบอยู่บน SQL แล้วเอาไปให้คนที่ไม่รู้ SQL ใช้

  • ในฐานะคนที่นำทีม data engineering/data science มามากกว่า 15 ปี บอกได้เลยว่านี่แหละคือประเด็นสำคัญ
    มีคนจำนวนมากที่เข้าถึงข้อมูลได้ แต่ไม่เข้าใจตัวข้อมูลเอง ความสัมพันธ์ของข้อมูล หรือผลลัพธ์ที่ตัวเองสร้างขึ้นหมายถึงอะไร
    ตลอด 25 ปีที่ผ่านมา ทั้งวิศวกรแบบกระจายศูนย์/embedded และนักวิทยาศาสตร์, แดชบอร์ดแบบ self-service, เครื่องมือ BI/ข้อมูลแบบ low-code, จนถึงตอนนี้คือ LLM ที่แปลงข้อความเป็น SQL/visualization ล้วนถูกเสนอเหมือนเป็นทางออก แต่สุดท้ายก็ยังแก้ปัญหา การขาดความเข้าใจข้อมูล และปัญหาความน่าเชื่อถือของผลลัพธ์ไม่ได้
    แต่ SQL เองก็ไม่ใช่คำตอบเช่นกัน มีคนจำนวนมากที่รู้ SQL พอจะดึงข้อมูลออกมาได้ แต่คนที่เข้าใจโครงสร้างข้อมูล สคีมา และวิธีใช้ที่ถูกต้องนั้นมีน้อย
    ตอนนี้ยังไม่มีเครื่องมือไหนแก้ปัญหานี้ได้นอกจากประสบการณ์ และแม้ LLM อาจทำได้ในอนาคต แต่พูดตามตรงก็ดูมีโอกาสไม่สูงนัก
    แดชบอร์ดเหมาะกับการดู KPI อย่างรวดเร็วแล้วค่อยเจาะลึก แต่สุดท้ายสิ่งสำคัญคือ แนวปฏิบัติด้านการจัดการข้อมูล และความสามารถในการเข้าใจข้อมูล/ความสัมพันธ์/ตัวชี้วัดอย่างถูกต้องแล้วเชื่อมโยงไปสู่ insight ทางธุรกิจ
    อนาคตนั้นน่าตื่นเต้น แต่จนถึงตอนนี้เครื่องมือเจเนอเรชันถัดไปก็ไม่เคยทำตามสัญญาได้จริง เลยไม่มีวันเชื่ออะไรง่าย ๆ อีก
  • เห็นเรื่องแบบนี้เกิดซ้ำแล้วซ้ำอีกในเครื่องมือ low-code
    ค่าเริ่มต้นที่ดูสมเหตุสมผล กับสิ่งที่ย้อนมาทำร้ายผู้ใช้นั้น ต่างกันแค่ที่มุมมอง
  • สงสัยว่าหลังแก้แล้วตัวเลขลดลง ทุกคนแตกตื่นกันหรือเปล่า
    เคยเห็นในบริษัทใหญ่ ๆ ว่าเมื่อบั๊กเล็กน้อยหรือการออกแบบบางอย่างทำให้รายได้ดูสูงขึ้น ก็จะไม่มีใครอยากไปแตะ เพราะไม่อยากรับผิดชอบกับ ยอดรายได้ที่ลดลง
    เช่น ปุ่มแพ็กเกจฟรีอยู่ใต้จอพับจากค่าเริ่มต้นของความละเอียดหน้าจอ หรือคำนวณรัฐผิดจนส่วนลดไม่ถูกใช้ หรือมีคนลืม false ไปตัวหนึ่ง ทำให้ระบบบังคับสมัครสมาชิกทั้งที่ในทางเทคนิคไม่จำเป็น
    เลยสงสัยว่าตอนตัวเลขลดลงจะมีบรรยากาศคล้าย ๆ กัน คือกลัวว่าจะถูกโทษว่าเป็นความผิดของตัวเองไหม
  • นี่เป็นปัญหาร่วมของทางแก้แบบ no-code ทั้งหมด
    เวลาจะทำตรรกะที่ซับซ้อน ส่วนที่ยากไม่ใช่การพิมพ์โค้ดลง IDE แต่คือความสามารถในการจำลองปัญหาและออกแบบอัลกอริทึมที่มีประสิทธิภาพ
    เครื่องมือพวกนี้เจาะกลุ่มผู้ใช้ที่ไม่ใช่สายเทคนิคด้วยคำสัญญาว่าไม่ต้องเขียนโค้ด แต่ผู้ใช้ก็ยังไม่เข้าใจส่วนที่ซับซ้อนของการออกแบบวิธีแก้แบบวิศวกรรมอยู่ดี จึงหลงทางหรือได้ผลลัพธ์ที่ผิด
    ความพยายามจะขยายกระบวนการธุรกิจที่ซับซ้อนด้วยเครื่องมือ no-code สุดท้ายมักชนกำแพงหลังลองผิดลองถูกมากมาย แล้วท้ายที่สุดก็ต้องส่งต่อให้วิศวกรจริงมารับช่วง
    แต่พอถึงตอนนั้น วิศวกรกลับต้องทำงานโดยไม่มีสิ่งสนับสนุนพื้นฐานที่ปกติมีเมื่อเขียนโค้ดด้วยภาษาโปรแกรมจริง
    เมื่อถูกขังอยู่ใน visual flow builder ก็แทบเป็นไปไม่ได้เลยที่จะมี shared repository, version control ที่ใช้งานได้จริง, code review, automated test และ CI/CD
  • ก็ทำแบบที่ที่อื่นทำสิ สร้างความสัมพันธ์เชิงนามธรรมขึ้นมาเป็น view แล้วจำกัดแดชบอร์ด BI แบบ self-service ให้ใช้เฉพาะ view ที่มีความหมายถูกต้อง
    โดยพื้นฐานแล้วผู้ใช้จะมองจากมุมของตัวเองเท่านั้น ดังนั้นต้องเตรียมวิธีทางเลือกที่ทำให้พวกเขามองเห็นได้ในแบบที่พวกเขาคิด
    รู้จักผลิตภัณฑ์หนึ่งที่จัดการการเช็กชื่อเพื่อการศึกษาแบบอิงเวลา เพราะแต่ละโรงเรียน วิทยาเขต และวัน มีชุดตารางเรียนต่างกัน และยังต้องยืดหยุ่นพอสำหรับกิจกรรมกีฬา การทำงานทดแทน กิจกรรมรวมชั้น หรือแม้แต่ตารางหมุนเวียน 14 วัน
    แต่ก็ไม่ได้แปลว่าจะสร้าง view ที่สังเคราะห์ตารางเรียนซับซ้อนนั้นออกมาเป็นการเช็กชื่อรายวิชาหรือการเช็กชื่อช่วงเช้า/บ่ายไม่ได้

• สมมติฐานที่ว่าผู้ใช้ฝั่งธุรกิจเรียนรู้ความสัมพันธ์ระหว่างคำถามของตัวเอง, data model และ dropdown ไม่ได้ หรือใจร้อนเกินไปนั้นไร้สาระมาก
  ตรงกันข้าม จากประสบการณ์พบว่าคนกลุ่มนี้อยากเรียนรู้ แต่บ่อยครั้ง data modeler กลับไม่เข้าใจโดเมนดีพอ จึงเก็บความละเอียดอ่อนของคำถามไว้ไม่ได้
  ผลคือภายใต้ข้ออ้างว่าจะทำ self-service ให้ง่ายขึ้น กลับซ่อนความละเอียดอ่อนไว้จนใช้เวลาหาคำตอบนานขึ้น หรือไม่ก็ลบมันทิ้งไปเลยจนได้คำตอบที่ไม่แม่นยำและชวนให้เข้าใจผิด
  ผมยังไม่ชอบคำเลี่ยงว่า ไม่ใช่สายเทคนิค ด้วย ระหว่าง LLM, เครื่องมือสร้างคิวรี BI และ SQL มันมีพื้นที่ตรงกลางอยู่มากพอ ไม่จำเป็นต้องประกาศว่ากำแพงด้านทักษะนั้นเป็นอะไรที่ข้ามไม่ได้

  • เรื่องนี้ยังโยงกับคำแนะนำที่ผมให้คนหนุ่มสาวที่สนใจการเขียนโปรแกรมอยู่เสมอ
    การเป็นผู้เชี่ยวชาญด้านคอมพิวเตอร์ การเขียนโปรแกรม หรือการวิเคราะห์ข้อมูลเป็นเรื่องที่ดี แต่ถ้าเป็นไปได้ก็ควรยึด โดเมน ที่ตนเรียนหรือทำงานเป็นแกน แล้วค่อยพัฒนาทักษะเหล่านั้นเป็นส่วนเสริม
    ทางแก้ของปัญหาที่ผู้เชี่ยวชาญโดเมนไม่รู้เรื่องข้อมูล และผู้เชี่ยวชาญข้อมูลไม่รู้เรื่องโดเมน ก็คือทำให้สองคนนั้นเป็นคนเดียวกัน
  • ผลลัพธ์ทางธุรกิจ/ข้อมูลที่ดีที่สุดในอาชีพของผมเกิดขึ้นตอนที่มี PM ที่รู้ SQL, เครื่องมือดึงข้อมูล/จัดตารางงานแบบเรียบง่าย และ data model ที่สมเหตุสมผลซึ่งทีม data engineering ดูแล โดยรับอินพุตหรือการออกแบบตารางมาจากนักพัฒนา BI

• ตอนนี้ดูเหมือนว่าความไร้ความสามารถในระดับองค์กรจะไปถึงอีกขั้นแล้ว
  เคยมีการ์ตูน Dilbert ที่ล้อเรื่องสเปรดชีต ซึ่งเอามาใช้กับเครื่องมือ BI และ AI ได้ตรงเป๊ะ
  ประมาณว่า “สเปรดชีตสำหรับงานนำเสนอนี้เต็มไปด้วยข้อผิดพลาดและข้อมูลผิด ๆ อยู่แล้ว แต่ไม่เป็นไรหรอก เพราะถ้ามันไม่ได้ช่วยตอกย้ำการตัดสินใจที่ผู้บริหารตัดสินไปแล้ว ก็ไม่มีใครกลับมาดูมันอีกอยู่ดี”
  ในโลกจริงก็มีรายงานและแดชบอร์ดพัง ๆ อยู่เต็มไปหมด
  บางครั้งไม่ถูกอัปเดตเลยเป็นเดือน ๆ หรือบางทีก็เป็นปี ๆ โดยไม่มีใครรู้ แต่ก็ยังถูกใช้ในกระบวนการ การตัดสินใจ และ workflow การทำงาน
  บางกรณีข้อมูลไม่ได้อัปเดต แต่มีการ pivot ตามวัน/เวลาแล้วจัดเรียงข้อมูลเดิมใหม่ทุกครั้งที่รัน จึงดูไม่ออกว่าพังหนักแค่ไหน
  และบ่อยมากที่สูตรต่าง ๆ กับ “คณิตศาสตร์” ข้างในผิดหมด จนสร้าง ตัวเลขในโลกแฟนตาซี ออกมา

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

• ตลอด 24 ปีที่ผ่านมา มีการส่งมอบข้อมูลให้ผู้ใช้ฝั่งธุรกิจมาโดยตลอด ไม่ว่าจะเป็นเครื่องมือ query, MS Access, Power BI หรือ data cube ของ Excel แต่คนที่ใช้งานจริงมีอยู่เพียงส่วนน้อย
  น่าจะเป็นคนกลุ่มเดียวกับที่เมื่อ 40 ปีก่อนก็ดึงข้อมูลจากเทอร์มินัลและรายงานที่พิมพ์ออกมาเพื่อวิเคราะห์
  ถึงอย่างนั้น ผู้บริหารก็ยังชอบแดชบอร์ดตัวชี้วัดหลัก และเครื่องมือ BI รุ่นใหม่ก็ช่วยให้สร้างและดูแล แดชบอร์ด KPI ได้ง่ายขึ้นมาก

  • เป็นเรื่องดีถ้าคุณเจอคนในบริษัทที่ไม่รู้ด้วยซ้ำว่าตัวเองเขียนโค้ดเก่งแค่ไหน
    ตำแหน่งงานอาจจะเป็นอะไรอย่าง “ผู้ช่วยส่วนตัว” แต่กลับจัดการ SharePoint forms, Access และ Excel ได้อย่างกับแฮ็กเกอร์จนทำของเจ๋ง ๆ ออกมาได้
    การยอมรับความสามารถอันชาญฉลาดของพวกเขาและมอบเครื่องมือที่ทรงพลังยิ่งขึ้นให้นั้นเป็นเรื่องที่ยอดเยี่ยม แล้วพวกเขาอาจย้ายไปทำงานที่ดีกว่าเดิม ซึ่งก็เป็นเรื่องดีเช่นกัน
  • ในยุคแรกของการประมวลผล งานส่วนใหญ่เกิดขึ้นบน เมนเฟรม ขนาดใหญ่ที่ใช้ร่วมกัน
    คอมพิวเตอร์มีราคาแพงมากจน “แผนกคอมพิวเตอร์” กลายเป็นหน่วยงานแยกภายในบริษัท และถ้าฝ่ายธุรกิจฝั่งตะวันตกต้องการทรัพยากรคอมพิวต์ ก็ต้องทำข้อตกลงกับแผนกคอมพิวเตอร์ที่มีเมนเฟรมติดตั้งอยู่ในพื้นที่
    กลุ่มของเราคือทีมวิเคราะห์ภายในขนาดเล็กที่คล่องตัว ใช้มินิคอมพิวเตอร์รุ่นใหม่ที่ “ราคาถูก”
    ข้อดีคือด้วยโครงสร้างเงินทุนแบบนั้น เราตอบสนองต่อความต้องการของผู้ใช้ได้เร็วกว่ามาก
    วันหนึ่งตอนเดินผ่านโรงงาน ผมเห็นผู้ใช้ตัดบรรทัดจากรายงานกระดาษแถบสีเขียวที่เราทำขึ้น แล้วเอาไปแปะลงบนกระดาษอีกแผ่นเพื่อถ่ายเอกสาร
    เขากำลังจัดเรียงรายงานใหม่ตามเกณฑ์อื่นอยู่ ผมเลยบอกว่า “แบบนั้นเราทำให้ได้!” แล้วคำตอบที่ได้กลับมาคือ “จริงเหรอ?”
    คนที่ต้องทำงานให้เสร็จก็จะหาวิธีทำให้เสร็จอยู่ดี เป้าหมายของทีมระบบคอมพิวเตอร์ที่ให้บริการลูกค้าภายในคือทำให้กระบวนการนั้นมีประสิทธิภาพที่สุด
    อีกคนหนึ่งใช้ PC, tablet digitizer และ AutoCAD เพื่อบันทึกจุดบนรูปเครื่องบินและสร้าง radar profile
    นั่นไม่ใช่การใช้ CAD ตามวัตถุประสงค์ดั้งเดิมนัก แต่เป็นวิธีใช้แบบสร้างสรรค์เพื่อเก็บข้อมูลจากแบบร่างใน Jane's Combat Aircraft
  • เวลาได้รับงานให้พัฒนาซอฟต์แวร์สำหรับ system integration แค่ตั้งค่าหรือเปิดเผยแดชบอร์ดที่มีอยู่เดิมให้ลูกค้าเห็น ก็มักทำให้ลูกค้าตกใจมากแล้ว
    พวกเขาแทบไม่เชื่อว่าข้อมูลนั้นมีอยู่แล้วตั้งแต่แรก
    การรวมระบบเป็นงานดำเนินธุรกิจที่จำเป็น แต่ข้อมูลที่เข้าใจง่ายเป็นสิ่งที่ผู้มีส่วนได้ส่วนเสียชอบมาก เป็น การเพิ่มมูลค่า ที่ง่ายมาก

• อินเทอร์เฟซ BI แบบดั้งเดิมที่พูดถึงในบทความคือ Metabase ซึ่งถือว่าค่อนข้างดีกว่าอินเทอร์เฟซ BI หลายตัวในปัจจุบัน
  Metabase ให้ดู SQL ที่ GUI สร้างขึ้นได้ และยังแปลงคำถามนั้นเป็น SQL ล้วน ๆ ได้ด้วย จึงเหมาะกับการก้าวจาก self-service ไปสู่ governance
  แก้ไขและตรวจสอบ logic ได้ง่าย และยังเปิดเส้นทางให้คนที่มีทักษะทางเทคนิคน้อยค่อย ๆ พัฒนาฝีมือได้
  แต่ประเด็นหลักของบทความก็ยังถูกต้อง แม้จากมุมของคนที่ทำงานด้านข้อมูลโดยตรง เครื่องมือ BI ก็มักไม่ค่อยทำให้คนจำนวนมากขึ้นเข้าใจข้อมูลได้ถูกต้อง หรือมีทักษะที่จำเป็นต่อการใช้อย่างถูกต้อง
  ถ้าข้อมูลถูกจัดการมาดี เครื่องมือก็จะใช้ง่ายและคนก็พอค้นหาคำตอบเองได้ แต่โลกมันซับซ้อน ข้อมูลก็เลยซับซ้อนไปด้วย
  ต้นทุนการจัดการข้อมูล มองเห็นได้ชัด แต่ประโยชน์กลับมองเห็นได้ยาก

• ผมก็ได้ข้อสรุปคล้ายกันเกี่ยวกับ “self-service BI” แต่แนวทางแก้ต่างออกไปเล็กน้อย
  ผมคิดว่าควรยกระดับชั้น abstraction ให้สูงขึ้น สร้างแดชบอร์ดที่ปรับแต่งได้มาก แต่ไม่เปิดให้ผู้ใช้ธุรกิจเห็น SQL จะดีกว่า
  ตัวอย่างเช่น แดชบอร์ดที่มี filter 20 ตัว มีมิติสำหรับการ breakdown และมีพารามิเตอร์อีก 20 ตัวไว้ควบคุม “สมมติฐานที่ใช้”
  คำถามอย่าง “อยากดูผลลัพธ์โฆษณา Google ของเดือนที่แล้วแยกตามช่วงอายุ” ก็จะกลายเป็นแค่การเปลี่ยน dropdown ที่กำหนดไว้ล่วงหน้า 3-4 จุด
  พารามิเตอร์คือหัวใจสำคัญ เพราะเราจะเปิดให้ใช้เฉพาะตัวควบคุมที่ผ่านการตรวจสอบแล้ว และไม่อนุญาต SQL ตามอำเภอใจ
  แน่นอนว่าแดชบอร์ดแบบนี้สร้างยาก และต้องใช้ความเชี่ยวชาญด้าน visualization พอสมควรใน Looker, Tableau หรือ Excel แต่สุดท้ายแล้วคำถามราว 70% จะกลายเป็น self-service ได้
  ส่วนอีก 30% ที่เหลือ ปล่อยมันไปจะดีกว่า และยังต้องมีคนที่แปลคำถามทางธุรกิจให้เป็นคำถามด้านข้อมูลอยู่ดี นั่นคือ ปัญหาด้านคน

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

• เราใช้ Metabase ที่อยู่ในภาพ และโดยรวมแล้วผู้ใช้ที่ไม่ใช่สายเทคนิคก็ใช้งานจริง
  สิ่งที่ช่วยให้การนำไปใช้ได้ผลคือการจัด “office hours” แล้วสาธิตตัวอย่างตรง ๆ เช่น “จะดึงยอดขายของสาขาหรือรัฐที่ต้องการอย่างไร”
  มันไม่ได้แก้ทุกปัญหา ทุก query หรือทุกการ export แต่คำขอจำนวนมากที่เมื่อก่อนต้องส่งมาถึงทีมวิศวกรรม ตอนนี้ไม่ต้องมาถึงขั้นนั้นแล้ว
  อีกเหตุผลที่ Metabase ดีคือมัน self-host ได้ และใช้ GSuite SSO ได้

  • จากประสบการณ์ของผม ปัญหาไม่ได้อยู่ที่วิธี query ข้อมูล แต่อยู่ที่ บริบทเฉพาะทาง ของตัวข้อมูลเอง
    ตัวชี้วัดหลักไม่ใช่ว่า “คำขอความช่วยเหลือลดลง แปลว่าผู้ใช้พึ่งพาตัวเองได้มากขึ้น”
    เพราะมีโอกาสสูงมากที่ผู้ใช้เหล่านั้นจะดึงและตีความตัวชี้วัดที่ผิดเพี้ยนแบบสุด ๆ
    ผมเห็นซ้ำแล้วซ้ำเล่าว่าเมื่อผู้ใช้ที่มีทักษะต่ำเข้าถึงข้อมูลได้ พวกเขาจะเชื่อว่า “มันไม่ได้ยากอย่างที่คิด” แล้วก็เริ่มก่อพีระมิดของการวิเคราะห์ผิด ๆ
    การวิเคราะห์ที่ถูกต้องต้องมีบริบทเสมอ
    ตัวอย่างเช่น รายได้แบบ recurring ห้ามใช้วันจัดส่งมาคำนวณรายได้รายเดือน เพราะทีมการเงินจะกรอกวันจัดส่งใหม่
    ราคาตามแคตตาล็อกถูกเก็บเป็น USD แต่ในความเป็นจริงจะมีการปรับอัตราแลกเปลี่ยนรายเดือนตามตาราง monthly_discount
    ตามธรรมเนียมในการแสดงสต็อกคงค้างจากปีก่อน รายการที่มีวันที่ซื้อเป็น null ต้องตัดออกจากรายงานยอดขาย
    และเพราะราคาถูกเก็บเป็นสกุลเงินท้องถิ่น จึงห้ามรวมยอดขายโดยไม่ join กับตารางอัตราแลกเปลี่ยน
  • Metabase ดีมาก
    ผมตั้งค่าไว้ให้คนที่ไม่เขียนโปรแกรมในบริษัทใช้ และพูดตามตรง พวกเขาแทบไม่ได้ใช้อะไรมากไปกว่าการเปิดดูแดชบอร์ดที่ผมทำไว้ แต่ผลตอบรับก็ดี
    มันเป็นเครื่องมือที่มีประโยชน์มากจริง ๆ

• เป็นเรื่องน่าขำเสมอที่ผู้บริหารระดับสูงได้เงินก้อนโต แต่กลับรัน BI SQL query ไม่ได้
  เดิมที SQL ก็ถูกสร้างมาเพื่อให้ผู้จัดการ query ข้อมูลได้ง่ายขึ้น
  ในฐานะอดีตพนักงานขาย/ผู้จัดการ เลยไม่ค่อยรู้สึกเห็นใจคนประเภทนั้นเท่าไร

  • ผมรู้จัก CEO คนหนึ่งที่ “ทำ” SQL ได้ และทำได้เก่งกว่าคนส่วนใหญ่ในบริษัทที่บอกว่าตัวเองทำ SQL เป็นเสียอีก
    แต่เขาไม่ทำเอง เพราะเข้าใจหลักเศรษฐศาสตร์พื้นฐาน
    ต่อให้เขาทำงานที่คนอื่นต้องใช้เวลา 3 วันให้เสร็จได้ในครึ่งวัน แต่ครึ่งวันนั้นก็คือเวลาที่เขาไม่ได้ทำงานที่มีแค่ CEO เท่านั้นที่ทำได้
    CxO ที่มีความสามารถยังรู้ด้วยว่าส่วนที่กินเวลาจริง ๆ คือการเก็บรายละเอียดให้ถูกต้องสมบูรณ์
    ต่อให้ SQL จะเป็น “ระดับสูง” แค่ไหน ก็ยังต้องใช้เวลาและสมาธิเพื่อให้ได้คำตอบที่เชื่อถือได้ เช่น ความแปลกของการจัดการ null, การจัดการวันที่, และการ merge ที่ไม่เข้ากัน
    ถ้ามีคนที่เชี่ยวชาญเรื่องนี้โดยเฉพาะ ก็ควรให้คนนั้นทำ

• ผมคิดว่า BI dashboard ใช้งานได้ดีกับ query ที่ง่ายมาก ๆ
  ถ้าถึงขั้นต้องให้ผู้ใช้ที่ไม่ใช่สายเทคนิคมาทำ data join เอง แปลว่าลงลึกเกินไปแล้ว และถึงตอนนั้นใช้ SQL ไปเลยน่าจะดีกว่า
  join อาจดูเป็นเรื่องพื้นฐานสำหรับบางคน แต่ส่วนตัวผมเองก็ยังรู้สึกว่าเข้าใจยากเป็นบางครั้ง และเมื่ออยู่ใน UI ของ dashboard ที่แสดงความหมายได้น้อยกว่า SQL ก็ยิ่งเป็นส่วนผสมที่ชวนสับสน
  สุดท้ายมันคือการประนีประนอม ทำให้ผู้ใช้ที่ไม่ใช่สายเทคนิคเข้าถึงได้ง่ายกว่า SQL ก็จริง แต่ก็ต้องทรงพลังน้อยกว่า SQL อย่างหลีกเลี่ยงไม่ได้
  ถึงอย่างนั้น พื้นที่ตรงกลางนี้ก็ยังมีประโยชน์มาก ในความเป็นจริง “BI” จำนวนไม่น้อยก็อยู่ในระดับ “มีคอลัมน์ข้อมูล 2 คอลัมน์ ช่วย plot อันหนึ่งเทียบกับอีกอันให้หน่อย”
  ผู้เขียนบอกว่า SQL คือเครื่องมือ BI แบบ “self-service” เพียงอย่างเดียว แต่เอาจริง ๆ ผมว่าอันนั้นคือ Excel
  เครื่องมือ BI จำนวนมากใกล้เคียงกับการเอา Excel มาสร้างใหม่ในอินเทอร์เฟซที่ใหม่กว่า และเลยคุ้นมือน้อยกว่า
  ผมคิดว่ามีมที่ไม่ชอบ Excel เกิดจากอดีตที่คนพยายามใช้ Excel ทำเรื่องซับซ้อน
  ถ้าทำ data manipulation ที่ซับซ้อนด้วย SQL แล้วใช้ Excel สำหรับ “แสดงอันนี้เป็น pie chart ให้หน่อย” ก็อาจไม่จำเป็นต้องมีเครื่องมือ BI เลยจริง ๆ

  • ผมก็เกือบจะพูดเรื่องความสัมพันธ์ระหว่าง SQL กับ Excel แบบเดียวกันนี้เหมือนกัน
    ถ้าแหล่งข้อมูลต้นทางถูกจัดระเบียบ, transform และควบคุมสิทธิ์การเข้าถึงไว้อย่างดี แค่ VLOOKUP กับ pivot ก็ไปได้ไกลอย่างน่าทึ่งแล้ว
    พอมีแหล่งข้อมูลมากกว่าหนึ่งแหล่ง การเปิดโอกาสให้ผู้ใช้ที่ไม่ใช่สายเทคนิคทำ self-service เอง มักจะจบลงที่การเอาข้อมูลออฟไลน์มาปนกันมั่ว
    แล้วก็จะมีคำถามว่า “ทีมข้อมูล ทำไมข้อมูลของ ‘พวกคุณ’ ถึงไม่ตรงกับข้อมูลของ ‘ฉัน’ ล่ะ?” ซึ่งก็ตั้งต้นจากสมมติฐานเสมอว่าฝั่งตัวเองถูก

• ปัญหาหลักคือเครื่องมือสมัยใหม่ต่างจากเดสก์ท็อปแบบคลาสสิกอย่าง Smalltalk workstation หรือ Emacs
  สภาพแวดล้อมแบบนั้นเป็นระบบที่บูรณาการครบวงจรเพียงหนึ่งเดียว ทุกอย่างอยู่ในมือผู้ใช้ และมีแนวคิด end-user programming ฝังอยู่ในตัว
  ใน org-mode คุณสามารถสร้างสไลด์ที่ดูดีได้แทบจะทันที เขียนและรัน code snippet แบบเร็ว ๆ แล้วเอาผลลัพธ์ออกมาได้
  แต่ในมุมของ dashboard มันมีข้อจำกัดมาก แม้จะ plot ข้อมูลได้เร็ว แต่ผลลัพธ์ก็ใกล้เคียงภาพนิ่งหยาบ ๆ และถ้าจะทำให้สวยด้วย PGF/TikZ ก็ใช้เวลามากเกินไปจนแทบไม่ใช่ตัวเลือก แถมก็ยังเป็นภาพนิ่งอยู่ดี
  ตัว Emacs เองเป็นเครื่องมือที่ใช่ แต่เป็นเครื่องมือของยุคที่เก่ากว่า
  เครื่องมือสมัยใหม่ให้หน้าตาที่ฉูดฉาดกว่าและการโต้ตอบที่เร็วกว่า แต่กลับทำได้แค่พฤติกรรมที่จำกัดมาก ติดอยู่ใน UI ที่ไม่ยืดหยุ่น และยังไม่เชื่อมรวมกับอย่างอื่นด้วย
  R เมื่อใช้ร่วมกับ RStudio/quarto อาจเป็นวิธีที่เร็วที่สุดในการสร้างคอนเทนต์ที่ดูดี แม้จะเร็วและค่อนข้างเลอะเทอะ แต่ก็ยังห่างไกลจากความยืดหยุ่นของ Emacs มาก
  สุดท้ายแล้วก็ดูเหมือนไม่มีทางออก นอกจากจะเขียน modern software stack ทั้งก้อน ขึ้นใหม่บนพื้นฐานของกระบวนทัศน์แบบคลาสสิกและสมรรถนะฮาร์ดแวร์สมัยใหม่