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

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

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

โดยส่วนตัวแล้ว ผมแบ่งประเภทของ requirement ออกเป็นสามแบบคร่าวๆ คือความต้องการทางธุรกิจ ความต้องการด้านข้อมูล และความต้องการทางด้านระบบ

Business Requirements

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

Data Requirements

จากความต้องการทางธุรกิจ ก็ส่งผลให้เกิดความต้องการด้านข้อมูลขึ้นมา เพื่อตอบคำถามต่างๆ ที่ผู้ใช้ต้องการ แน่นอนที่ว่าจะต้องมีข้อมูลเป็นฐานในการสร้างคำตอบ ความต้องการด้านข้อมูล จะเป็นการพิจารณาข้อมูลแต่ละอย่างในแง่มุมที่แตกต่างกัน ไม่ว่าจะเป็นนิยามของข้อมูล ความละเอียดของข้อมูล (granularity) มิติต่างๆ ที่จะต้องใช้เพื่อทำการวิเคราะห์ข้อมูลนั้นๆ (dimension) ความทันสมัยของข้อมูล (timeliness) และระยะเวลาการเก็บข้อมูล (retention)

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

โดยทั่วไปแล้ว data requirements จะเป็นตัวบอกว่า เราจะออกแบบ data warehouse อย่างไร ต้องเก็บข้อมูลมากน้อยเพียงใด จะปรับปรุงข้อมูลในคลังบ่อยแค่ไหน และอาจจะรวมไปถึงการแสดงข้อมูลต่อผู้ใช้อย่างไรด้วย

System Requirements

ทั้ง business และ data requirements จะเป็นตัวกำหนดความต้องการทางเทคนิคของระบบ ว่าระบบงาน BI ที่เราต้องการนั้น จะมีลักษณะหรือความสามารถทางเทคนิคอย่างไรบ้าง เช่น เมื่อผู้ใช้เปลี่ยนขอบเขตหรือตัวเลือกของข้อมูลอ้างอิง ระบบจะต้องสามารถคำนวณข้อมูลให้ใหม่ได้ภายในเวลาไม่เกิน x วินาที เป็นต้น จะต้องสามารถโหลดข้อมูลใหม่ในแต่ละวันจำนวน 20 ล้านแถวได้ภายในเวลา x ชั่วโมง เป็นต้น

ปัญหาที่ผมพบบ่อยก็คือ นักวิเคราะห์ระบบบางคน หรือบางทีก็รวมไปถึงผู้ใช้เองด้วย ไม่ได้แยกประเภทความต้องการเหล่านี้ออกมา ก็เรียกรวมๆ กันเลยว่าเนี่ย business requirement ฉันต้องการรายงานหน้าตาอย่างนี้นะ update ทุกวัน แสดงข้อมูลย้อนหลังได้ 5 ปี ถ้ากดอย่างนี้ ได้ผลลัพธ์อย่างนี้ เรียกได้ว่า ทำทุกอย่างเหมามาหมด ออกมาเป็น system requirement เลย ยื่นให้โปรแกรมเมอร์ลงมือทำเลยทันที (โดยมากมักมาในรูปแบบของ report format หรือไม่ก็ system mockup) ทางด้านโปรแกรมเมอร์หรือ system owner บางทีก็บ้าจี้ตามไปด้วย รับอะไรมาก็ก้มหน้าก้มตาทำกันไป

ทีนี้ปัญหามันมาเกิดตรงที่ บางครั้งระบบหรือความต้องการอย่างใดอย่างหนึ่ง มันเป็นส่วนหนึ่งของแพลตฟอร์มหรือโครงการที่ใหญ่กว่านั้น แถมยิ่งพอเราใช้ data warehouse เป็นหลักในการเก็บข้อมูล การปรับเปลี่ยนแก้ไขโดยดูจาก system requirement อย่างเดียว บางทีก็ส่งผลกระทบแย่ๆ ต่อการพัฒนาคลังข้อมูลเหมือนกัน หรือไม่บางทีก็กลายเป็นการขี่ช้างจับตั๊กแตนกันไป

หลายปีมาแล้ว ผมเคยปฎิเสธ change request ฉบับหนึ่ง ที่ขอให้เปลี่ยนวิธี aggregate ข้อมูลในรายงานจาก simple average มาใช้วิธี weighted average (อันนี้ผมมองว่าเป็น data/system requirements) โดยทาง analyst อ้างว่า ผู้ใช้เกิดข้อสงสัยในตัวรายงาน ว่าข้อมูลอาจจะไม่แม่นยำเพียงพอ (business requirement) เธอเลยเสนอให้เปลี่ยนวิธีคำนวณ ผมคำนวณดูคร่าวๆ แล้วพบว่า มันไม่ได้ช่วยอะไรเท่าไหร่ แค่เพิ่มความแม่นยำของตัวเลขรายงาน จากทศนิยม 1 ตำแหน่ง ทำให้ถูกต้องมากขึ้นจนถึงตำแหน่งที่ 3 เท่านั้นเอง แต่ต้องยกเครื่อง aggregation engine ใหม่ แถมใช้เวลา process รายงานนานขึ้น 2 เท่า เลยกลับไปถาม business sponsor ง่ายๆ ว่า ถ้าตัวเลขในรายงานเปลี่ยนไปจาก 81.2% ไปเป็น 81.1882% จากทำให้คุณตัดสินใจแตกต่างไปจากเดิมหรือไป แล้วถ้าจะต้องลงทุนอีก $xxx เพื่อให้ได้รายงานที่ละเอียดขึ้น คุณจะยอมจ่ายหรือเปล่า

สุดท้ายเราแก้ปัญหา business requirement ที่ต้องการข้อมูลที่แม่นยำขึ้น โดยการปรับเปลี่ยนขั้นตอนการเก็บข้อมูลครับ ไปเปลี่ยนเอาที่ต้นทางตอนเกิด transaction ขึ้น โดยไม่ได้เปลี่ยนแปลงอะไรในระบบ reporting system เลย เพราะเมื่อเราพิจารณาแยกส่วนกันระหว่าง business requirement กับ data/system requirement ก็พบว่าทางแก้ปัญหาที่เหมาะสมกว่า มันอยู่นอกระบบ BI นั่นเอง