Who Should Interpret These Reports

คราวที่แล้วผมเล่าเรื่องรายงานที่ออกแบบมาใหม่ โดยตั้งคำถามว่า "How users interpret reports" พยายามค้นหาว่าทำไมรายงานเหล่านั้นไม่สามารถสื่อสารให้ผู้ใช้เข้าใจและใช้ประโยชน์อย่างที่ตั้งใจ 

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

ประเด็นสำคัญอาจไม่ใช่การหาว่าผู้ใช้เหล่านั้นใช้รายงานอย่างไร แต่ "ผู้ใช้" แบบไหนที่ควรใช้รายงานเหล่านี้ต่างหาก

(1)

เมื่อไปตรวจสุขภาพที่โรงพยาบาล จะได้รายงานผลการตรวจสุขภาพ ซึ่งไม่ได้มีไว้ให้คุณอ่าน หากต้องการเข้าใจสิ่งที่อยู่ในรายงาน คุณต้องอาศัยผู้เชี่ยวชาญ(หมอ)ช่วยอ่านแล้วอธิบายอีกทีหนึ่ง

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

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

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

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

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

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

ตอนที่ผมจินตนาการว่า AI จะกลายเป็นผู้อ่านรายงาน คำว่า "AI friendly report" ก็ผุดขึ้นมาในหัว สำหรับ LLM (Large Language Model) รายงานควรมีหน้าตาอย่างไร อาจไม่จำเป็นต้องออกแบบให้อ่านง่ายในสายตามนุษย์ ไม่ต้องทำตารางแบ่งช่องอีกต่อไป

(2)

ย้อนกลับไปเมื่อสัปดาห์ที่แล้วผมเพิ่งออกแบบรายงานที่ติดค้างมานาน เป็นรายงานที่ใช้ตรวจใบภาษีหัก ณ จ่าย ภงด.3, 53 และทุกภงด.

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

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

นอกจากนี้ยังมียอดนำส่งที่ตามปกติจะบันทึกนำส่งภาษีในเดือนถัดไป ที่จะต้องเก็บมาพิสูจน์

ทำออกมาเสร็จก็นึกขำกับตัวเองว่า เป็นรายงานที่ทำมาแทบตาย ต้องเชื่อมโยงข้อมูลซับซ้อน เพื่อสรุปออกมาให้เหลือเพียงบรรทัดเดียว 

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

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

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

(3)

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

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

• ถ้าเราไม่จำเป็นต้องทำหน้าที่ตรวจทานความถูกต้อง (transactional report)

• ถ้าเราไม่จำเป็นต้องทำหน้าที่สรุปรายงานส่งหัวหน้า (summary report)

• ถ้าเราไม่จำเป็นต้องทำหน้าที่วิเคราะห์ข้อมูลให้ผู้บริหาร (analysis & analytics report)

ตัวอย่างที่ชัดเจน เมื่อโปรแกรม ERP ที่เอาคอมพิวเตอร์มาเชื่อมโยงเก็บข้อมูลตั้งแต่กิจกรรมการทำงานต่างๆ แทนที่จะแยกใช้โปรแกรมบัญชีคอมพิวเตอร์เอกเทศ กลายเป็นว่าคอมพิวเตอร์สามารถสร้างรายการแยกประเภทได้ทันที จนแทบไม่เหลืองานเสมียนลงบัญชี (book keeper) 

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

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

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

สมมติว่ามีวิธีประมวลผลโดยวิธีอื่นโดยไม่ต้องตามวิธีคิดแบบบัญชีแยกประเภท แล้วค่อยย้อนกระบวนการจำลองผลลัพธ์ให้เสมือนทำบัญชี…

พอแค่นี้ก่อน ไม่กล้าเล่าเรื่องที่คิดไปไกลกว่านั้น “โปรแกรมเมอร์มีไว้ทำอะไร”