Dimensions, quantum times and measurements - rethinking about report

กิจการแห่งนี้มีข้อมูลบันทึกกิจกรรมทางบัญชีสะสมตลอดห้าปีเข้าสู่หลักล้าน ผมไม่แน่ใจว่าข้อมูลที่สะสมไว้นั้นมีค่าเพียงใด รู้แต่เพียงว่าในช่วงโควิดที่ผ่านมา ผู้ประกอบการก็ยังคงขยายสาขาสร้างคลังสินค้าเพิ่ม
 
นานมาแล้วมีเจ้าของกิจการอีกท่านหนึ่ง เล่าให้ฟังถึงการเริ่มต้นใหม่ หลังจากที่ในจังหวัดเกิดอุทกภัยและร้านโดนน้ำท่วม ก็เรียกรายงานสต็อกเพื่อประเมินความเสียหาย พร้อมๆ กับดูรายชื่อลูกค้าประวัติการขายที่ผ่านมา บอกว่าโปรแกรมนี้ช่วยชีวิตเขาไว้ แต่ตอนนั้นไม่เข้าใจความหมาย ได้แต่จดจำคำนั้นไว้ ในยุคเริ่มต้นของโปรแกรมนี้ก็เคยเกิดปัญหาติดขัด กิจการแห่งหนึ่งทำงานไม่ได้ ดาต้าเบสทำงานไม่ทัน ที่จริงแล้วปัญหาดังกล่าวเริ่มเกิดขึ้นประปรายมาระยะหนึ่งแล้ว มีเสียงบ่นจากผู้ใช้มาบ้าง แต่ทางทีมงานผู้ดูแลก็ไม่สามารถหาสาเหตุที่แน่ชัด จึงได้แต่สุ่มแก้ปัญหาเท่าที่คาดเดาเอาเอง สุดท้ายการปิดเคสของปัญหา ก็ต้องใช้วิธีเผื่อให้เหลือไว้ก่อน ขยายขนาดเซิร์ฟเวอร์จนดาต้าเบสทำงานทัน เป็นการซื้อเวลาจนกว่าขีดความสามารถของเซิร์ฟเวอร์จะรับไม่ไหวอีกครั้งในอนาคต เหมือนนั่งทับระเบิดเวลาเอาไว้ ยังมีกิจการอีกหลายแห่งที่ดาต้าเบสเริ่มโตขึ้นเรื่อยๆ ผมนึกถึงการขับรถเดินทางไกล ทำไมต้องมีเกจ์แสดงความเร็ว, ระดับน้ำมัน, ระดับความร้อน ฯลฯ ตอนนี้ผมขับเคลื่อนโปรแกรมที่มีผู้ใช้เพิ่มขึ้นเรื่อยๆ โดยไม่รู้ระดับการใช้งานเลย 5 วินาทีสำหรับการค้นหา เป็นค่าที่กำหนดขึ้นมาเอง เมื่อคนคนหนึ่งสั่งค้นหาข้อมูล โปรแกรมควรตอบกลับมาได้ภายใน 5 วินาที ผมเริ่มต้นด้วยการสร้างกลไกจับเวลาการค้นหาในโปรแกรม หากโปรแกรมใช้เวลาเกินจะส่ง notify เข้ามาที่ Line Group ช่วยให้รู้ปัญหาว่าใครกำลังค้นหาอะไร โดยไม่รอให้ใครแจ้งเข้ามา
หลังจากนั้นก็ค่อยๆ เพิ่มการจับเวลาไปทีละส่วน เช่น เรียกรายงานในโปรแกรมไม่ควรเกิน 10 วินาที ฯลฯ เริ่มรู้สาเหตุ และสามารถแก้ไขได้ตรงจุดมากขึ้น
ถึงแม้ว่า notify จะช่วยให้รับรู้สาเหตุของปัญหาและแก้ไขสถานการณ์ได้ทันท่วงที เปรียบเสมือนหน่วยกู้ชีพที่ข่วยให้ผ่านวิกฤติเป็นครั้งๆ ไป แต่ก็มีข้อจำกัดตรงที่ไม่สามารถบริหารจัดการปัญหาในภาพรวม
 
คำว่า "บริหารจัดการ" หมายถึงเมื่อมีปัญหาเข้ามารุมล้อมพร้อมๆ กัน คุณไม่สามารถรับมือได้ทั้งหมด จะต้องเลือกว่าควรจัดการเรื่องไหนก่อน ดูที่ความหนักเบา อะไรทำให้เกิดผลกระทบมากกว่า เหมือนนักดับเพลิงที่ต้องเลือกว่าจะดับไฟจุดไหนก่อน จำเหตุการณ์ไฟไหม้โรงงานเคมีแห่งหนึ่งได้ไหม ครั้งนั้นมีโดรนกู้ภัยมาช่วยถ่ายภาพสถานที่เกิดเหตุ ทำให้รู้จุดความร้อนที่เป็นต้นตอ จนสามารถเข้าไปปิดวาล์วถังเคมีก่อนที่จะลุกลามไปใหญ่โตกว่านี้
 
"ข้อมูล" ที่ผ่านการสังเคราะห์บางมิติจนช่วยให้เห็นจุดความร้อนที่เป็นสาเหตุชัดเจน เป็นภาพที่มีค่าสำหรับผู้ที่รู้ว่าจะจัดการอย่างไรต่อ
ใช่ครับ ผมกำลังคิดถึงรายงานอีกชนิดหนึ่ง ที่ไม่ใช่การเอารายละเอียดมาเรียงกันเป็นร้อยเป็นพันบรรทัดเพื่อให้พนักงานที่รับผิดชอบตรวจความถูกต้องอย่างที่คุ้นเคย แต่เป็นรายงานที่ใช้สำหรับบริหารจัดการในภาพรวม
 
ผมจะเล่าเรื่องนี้ผ่านการออกแบบรายงานที่ใช้บริหารจัดการโปรแกรม และคิดว่าสำหรับผู้ประกอบการ และผู้บริหารต่างก็ต้องการเกจ์วัดสถานะของกิจการที่ขับเคลื่อนในลักษณะนี้อยู่เช่นกัน
 
"มิติ"
 
ก่อนที่จะออกแบบรายงานต้องทำความเข้าใจข้อมูล เพื่อกำหนดมิติที่อยู่ในความสนใจ ความหมายของมิติ คือ การจัดกลุ่มของข้อมูลตามคุณสมบัติที่เหมือนกัน มิติที่ผมสนใจมีอยู่ 2 มิติ คือ site กับ user สถิติของปัญหาในระดับ site ช่วยให้รู้ว่าควรดูแลกิจการไหนก่อน ขณะที่สถิติของปัญหาระดับ user ช่วยบอกให้รู้ระดับของความไม่พอใจเป็นรายบุคคล ควรแก้ปัญหาให้ใครก่อน หากเป็นข้อมูลขายของกิจการมิติแบ่งได้เป็น ลูกค้า กับ สินค้า และอาจมีพนักงานขายด้วย
 
"ตัวเลขที่วัดค่า"
 
การวัดค่าปัญหาของโปรแกรม ผมใช้วิธีนับจำนวนครั้ง (count) ตามประเภทของการทำงานแต่ละประเภท ที่เกิดขึ้น ทำให้รู้ว่ามีการทำงานค้นหากี่ครั้ง และ มีการเรียกรายงานกี่ครั้ง เป็นต้น สำหรับผู้ประกอบการตัวเลขที่สำคัญคือ จำนวนเงินหรือยอดขาย, ยอดค้างชำระ และจำนวนบิล เทียบเท่าจำนวนครั้งที่ขายนั่นเอง
 
"ช่วงและก้อนเวลา"
 
รายงานที่ผมใช้เก็บข้อมูลไว้เพียง 7 วันล่าสุด ดังนั้นจึงออกแบบให้มีช่วงเวลาอยู่ 2 ระดับ คือ ภายในหนึ่งวัน กับ หลายวัน (7 วัน) ความสัมพันธ์ของช่วงเวลามีผลต่อการกำหนดก้อนเวลาที่เหมาะสม กรณีดูภายในวันจะใช้วัดค่าเป็นรายชั่วโมง หรือรายสิบนาที ขณะที่รายงานที่ใช้ดูหลายวันจะใช้วัดค่ารวมต่อวัน
ช่วงเวลาในการวิเคราะห์สถานะของกิจการทั่วไปจะยาวนานกว่านั้น ช่วงเวลาเป็นปีหรือหลายปีย้อนหลัง ก้อนเวลาที่เหมาะสมอาจเป็นรายปีหรือรายเดือน ส่วนรายงานที่ใช้ดูในช่วงปีเดียวหรือไม่เกินปี อาจวัดค่าเป็นรายเดือน หรือรายวัน
 
"แกนหลักและตัวกรอง"
 
จำนวนของรายงานเท่ากับจำนวนมิติและก้อนเวลา ที่นำมาใช้เป็นแกนหลัก ดังนั้นรายงานที่จะต้องสร้างทั้งหมดควรมีดังนี้
 
รายงานตาม site
รายงานตาม user
รายงานรายสิบนาที
รายงานรายชั่วโมง
รายงานรายวัน
 
มิติที่ไม่ได้เป็นแกนหลักจะใช้เป็นตัวกรองภายใต้รายงานนั้นได้ และใช้นับจำนวนด้วย เช่น รายงานตาม site สามารถนับจำนวน user และ รายงานตาม user สามารถนับจำนวน site (user บางคนทำงานหลาย site) และหากเลือกกรองเฉพาะ site เดียวภายใต้รายงานตาม user ก็จะกลายเป็นรายชื่อ user ของ site นั้น
กิจการทั่วไปก็สามารถออกแบบให้มีรายงานตามลูกค้า, สินค้า หรือพนักงาน แล้วผสมผสานตัวกรองเพื่อใช้ประโยชน์ในแง่มุมที่หลากหลายเช่นกัน
  
"เรียงลำดับและตัดรายการ"
 
ภายในรายงานที่ใช้มิติเป็นแกนหลักควรเรียงลำดับตามอะไร อย่าเรียงตามตัวอักษรเหมือนหน่วยงานราชการชอบใช้เด็ดขาด หลักคิดของผมพิจารณาที่ "ความสำคัญ" หรือ "ก่อให้เกิดผลกระทบ" ดังนั้น site ที่มีปริมาณใช้งานมากที่สุดจะอยู่ลำดับแรก เช่นกัน ลูกค้าที่มียอดซื้อมากที่สุดย่อมสำคัญกว่า จึงควรอยู่ลำดับแรก
บางครั้งถึงแม้จะย่นย่อข้อมูลแล้ว จำนวนรายการก็ยังมีมากเกินไปถึงระดับหลักร้อยหรือพัน อาจใช้เกณฑ์ 80/20 มาพิสูจน์ว่า มีเพียง 20% ของสมาชิกเท่านั้นที่ก่อให้เกิดผลกระทบ 80% เพื่อตัดจำนวนรายการให้เหลือเฉพาะเท่าที่สำคัญ
 
"คิดแบบผู้บริหาร"
 
เป็นคำที่ผมต้องเตือนตัวเองเสมอ "คิดอย่างผู้บริหาร ไม่ใช่นักบัญชี" สำหรับคนที่ออกแบบโปรแกรมให้นักบัญชีใช้มาตลอด มักติดกรอบความคิดที่ว่า ความผิดพลาดหรือคลาดเคลื่อนระดับเศษสตางค์ต้องไม่เกิดขึ้น ทุกรายการต้องครบถ้วน ตัวเลขต้องตรงเป๊ะ 100% แต่สำหรับผู้บริหาร ความคลาดเคลื่อนที่ไม่มีนัยยะสำคัญนั้นยอมรับได้ เมื่อดูตัวเลขระดับล้าน ไม่ต้องลงละเอียดหลักร้อย การเสียเวลาตรวจสอบจนช้าเกินไป การมีรายละเอียดที่มากเกินไป กลับเป็นปัญหามากกว่า
 
ในการดูรายงานวิเคราะห์ปัญหาโปรแกรมก็เช่นกัน เมื่อใช้ไปนานวันเข้าการดูสัญญาณความผิดปกติ ก็เริ่มชำนาญสามารถดูแค่ไม่เกิน 5 อันดับที่มีการใช้งานสูงสุดก็เพียงพอแล้ว นั่นเป็นเหตุผลที่ผมกล้าเสนอให้ตัดรายการที่มากเกินไป หากรายการเหล่านั้นรวมกันแล้วมีผลกระทบไม่เกิน 20% ออกไป อย่าเสียเวลานำเสนอให้รกสิ้นเปลือง หากคุณมีลูกค้าเป็นพันราย ก็ยังไม่ถึงเวลาที่มาพิจารณาลูกค้าที่ยอดซื้อเดือนละน้อยๆ

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


 
June 2022 / Sathit J.