BzInsight

Vuca ย่อมาจาก Volatility, uncertainty, complexity and ambiguity เดิมศัพท์คำนี้ใช้กันในวงการทหาร แต่เมื่อไม่นาน ก็เอามาใช้อธิบายลักษณะการสภาพแวดล้อมทางสังคมและเศรษฐกิจในปัจจุบัน slideshare ข้างล่างนี้อธิบายด้วยภาพไว้ได้น่าสนใจดี ถึงแม้หลายตัวอย่างจะอเมริกันจ๋าไปซักหน่อยก็เถอะ

ในขณะที่ดูเหมือน VUCA จะสร้างปัญหา แต่ถ้าเรามองไปถึงหนทางแก้ไข หรือทางที่จะอยู่รอดเติบโตได้ใน VUCA world คำตอบก็ดูเหมือนจะมีให้อยู่แล้ว (ดูคำอธิบายได้ในช่วงหลังๆ ของ slideshare นะครับ)

• V = Volatility –> Vision
• U = Uncertainty –> Understanding
• C = Complexity –> Clarity
• A = Ambiguity –> Agility

ลักษณะการ restatement แบบที่สองจะเป็นการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อมูลอ้างอิง (reference data หรือ master data) โดยเฉพาะ

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

ถึงแม้ว่าตัวข้อมูลธุรกรรมไม่มีการเปลี่ยนแปลง แต่การเปลี่ยนข้อมูลอ้างอิง ก็สามารถส่งผลให้ “เสมือน” ว่าข้อมูลในอดีตมีการเปลี่ยนแปลงไปได้เช่นกัน

• Hierarchy Change

Hierarchy หรือโครงสร้างลำดับขั้น เป็นหนึ่งในลักษณะที่สำคัญของข้อมูลอ้างอิง มีความสำคัญมากต่อการสรุปยอดข้อมูล หรือ aggregation โดยการกำหนดการจัดหมวดหมู่ของข้อมูลให้สอดคล้องกับ ความต้องการใช้งานในกลุ่มผู้ใช้แต่ละกลุ่ม ตัวอย่างเช่น ถ้าบริษัทของคุณมีลูกค้าซัก 1000 ราย และจัดแบ่งหมวดหมู่ตามโครงสร้างการบริหารของฝ่ายขาย ทีนี้สมมติบริษัทคุณแบ่งเขตการขายตามพื้นที่ที่อยู่ของลูกค้า คุณอาจจะมีผู้จัดการฝ่ายขาย 4 คน ประจำภาคเหนือ ใต้ กลาง และอีสาน แต่ละคนก็ดูแลลูกค้าที่มีที่อยู่อยู่ในภาคนั้นๆ ดังนั้น ระบบ business intelligence ที่ใช้รายงานยอดขาย ก็จะรวมยอดขายของลูกค้าแต่ละราย ตามเขตพื้นที่ที่ผู้จัดการฝ่ายขายแต่ละคนดูแลอยู่

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

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

ระบบ data warehouse หรือ business intelligence ที่ออกแบบมาเพื่อรองรับลักษณะการใช้งานเหล่านี้ จะมีการเก็บประวัติการเปลี่ยนแปลงของ hierarchy ไว้ (หรือถ้าเอาให้ง่ายกว่านั้นหน่อย ก็ใช้วิธีสร้าง hierarchy ใหม่ไปเสียเลย) อาจจะย้อนหลังไปซัก 2-3 เวอร์ชั่น เพื่อให้สามารถตอบสนองการวิเคราะห์ข้อมูลแบบพิเศษนี้ได้

• Attribute Change

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

ยอดขาย 100 ล้านบาทเท่ากัน อาจแสดงผลในรายงานแตกต่างกันในแต่ละปีได้ ถ้าใช้อัตราแลกเปลี่ยนที่แตกต่างกันของแต่ละปี

Reference data restatement ถือเป็นเรื่องปกติ และเป็นหนึ่งในข้อที่ควรพิจารณาเป็นอย่างยิ่งในการออกแบบคลังข้อมูลหรือระบบ business intelligence ใดๆ ข้อควรพิจารณาประกอบด้วย

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

โดยหลักการทั่วไปแล้ว ข้อมูลในคลังข้อมูลหรือ data warehouse จะมีลักษณะ non-volatile คือ ไม่มีการเปลี่ยนแปลงไปตามเวลา พอข้อมูลเข้าสู่คลังแล้ว มักจะอยู่ในรูปแบบอย่างนั้นไปตลอด แต่พอเอาเข้าจริง ก็มักจะพบกับความต้องการที่จะเปลี่ยนแปลงข้อมูลในคลังข้อมูลอยู่เสมอ เรียกกันว่า Data Restatement

Data Restatement ที่ผมประสบพบเจออยู่บ่อยๆ มีสองแบบ อย่างแรกเลยคือ transaction restatement ประเภทที่สองเรียกว่า reference data restatement ทั้งสองแบบนี้มีวัตถุประสงค์ที่แตกต่างกัน และต้องการการจัดการที่แตกต่างกันด้วย

Transaction Restatement

เป็นการเปลี่ยนแปลงข้อมูลธุรกรรมที่เกิดขึ้นในอดีต สมมติอย่างเช่น มีข้อมูลยอดขายสินค้า A ไปยังลูกค้า ก. ประจำวันที่ 1 ตุลาคม 52 ข้อมูลแรกสุดที่เข้ามาเก็บในคลังข้อมูลบันทึกได้ว่ายอดขายเป็น 100 บาท ตัวเลข 100 บาทนี้ได้ถูกนำไปเผยแพร่ หรือ publish รวมเข้ากับยอดขายสินค้าอื่นๆ ผู้บริหารอาจจะได้ทำการตัดสินใจอะไรบางอย่างไปเรียบร้อยแล้วเกี่ยวกับข้อมูลตัวนี้ (เช่น สั่งเพิ่มปริมาณการผลิตสินค้า A หรือ สั่งให้ส่วนลดพิเศษลูกค้า ก. ไปเรียบร้อยแล้ว) แต่แล้ว ภายหลังพบว่า ข้อมูลยอดขายที่แท้จริงเป็นแค่ 50 บาท จะเกิดอะไรขึ้น? และระบบคลังข้อมูลหรือระบบ business intelligence ควรจะตอบสนองกับกรณีเช่นนี้อย่างไร?

ประเด็นแรกที่ต้องพิจารณา ก็คือ ลักษณะ transaction restatement ควรจะถูกพิจารณาเป็นกรณียกเว้นพิเศษ เพราะถือเป็นการเปลี่ยนแปลงแก้ไขประวัติศาสตร์ โดยเฉพาะอย่างยิ่ง ถ้าเป็นเรื่องที่เกี่ยวข้องกับเงินๆ ทองๆ หรือเกี่ยวข้องกับผลการประกอบการของบริษัท การยอมให้เกิด transaction restatement โดยไม่มีกระบวนการควบคุมที่ดี อาจมีใครบางคนโดน audit เรียกไปคุย หรือแย่ยิ่งกว่านั้น อาจจะต้องถือว่ามีโทษทางกฎหมายด้วยเลยทีเดียว

ดังนั้นแล้วกระบวนการ transaction restatement ต้องได้รับการอนุมัติเป็นกรณีพิเศษ จากผู้บริหารที่สามารถรับผิดชอบผลทางกฎหมายที่จะตามมาจากการแก้ไขข้อมูลได้

สิ่งที่เราพอจะช่วยได้ ก็คือการออกแบบโครงสร้างข้อมูลใน data warehouse ให้รัดกุม ครอบคุลมกระบวนการทางธุรกิจทั้งหลายทั้งปวง อันเป็นที่มาของการแก้ไข transaction ในอดีต รวมไปถึงการทำงานร่วมกับระบบงานอื่นๆ เช่น SCM หรือ ERP เพื่อสร้างระบบควบคุมที่เหมาะสมด้วยเช่นกัน ตัวอย่างเช่น ลงวิเคราะห์กันดูว่า เพราะสาเหตุใดที่ทำให้ยอดขายซึ่งเคยเป็น 100 บาท เปลี่ยนเป็นแค่ 50 บาทได้? เราอาจจะพบว่า เกิดจากพนักงานคีย์ราคาผิด (ควบคุมผ่าน ERP) หรือคีย์จำนวนสินค้าผิด (ควบคุมผ่านกระบวนการส่งของ) หรืออาจจะเกิดจากการที่สินค้าจัดส่งไปแล้ว แต่ลูกค้าคืนสินค้ากลับมาครึ่งหนึง (แก้ไขโดยการออกแบบฐานข้อมูลที่รองรับการคืนสินค้า) เป็นต้น

เอาไว้คราวหน้ามาคุยให้ฟังเรื่อง reference data restatement ต่อแล้วกันครับ

สัปดาห์ที่แล้วผมใช้เวลาทั้งสัปดาห์อยู่ในประเทศจีน ทำ mapping & matching session ให้กับระบบ logistics โดยเน้นไปที่สองเรื่องคือการจัดการสินค้าคงคลัง และการบริหารคำสั่งซื้อที่ไม่สามารถตอบสนองได้ (order cut) เพื่อเพิ่มความสามารถในการให้บริการแก่ลูกค้า เราเข้าไปพร้อมกับระบบที่พัฒนาขึ้นมาเรียบร้อยแล้ว และมีการนำไปใช้งานได้ผลดีมากในรัสเซีย และกำลังจะนำมาใช้ในจีนแผ่นดินใหญ่ เป้าหมายง่ายๆ ที่เราตั้งกันไว้ก็คือ ควรจะสามารถสร้างระบบ BI ที่บอกผู้บริหารได้ว่า สถานการณ์สินค้าคงคลังเป็นอย่างไรบ้าง ในแต่ละประเทศ ลึกลงไปจนถึงขั้น แต่ละคลังสินค้าในส่วนของตัวแทนจำหน่ายแต่ละราย รวมถึงความสามารถในการให้บริการของตัวแทนจำหน่ายด้วย ว่าสามารถให้บริการลูกค้าได้ดีเพียงใด โดยดูจากเปอร์เซ็นต์การขายที่สามารถจัดส่งสินค้าได้ เทียบกับคำสั่งซื้อรวมที่ลูกค้าสั่งมา ระบบดังกล่าวนี้ ควรจะสามารถนำไปใช้ได้กับประเทศต่างๆ ได้โดยไม่ต้องเปลี่ยนแปลงแก้ไขอะไรมากมายนัก

การสร้างระบบ BI ที่จะทำให้ผู้บริหารสามารถเห็นภาพรวมของธุรกิจได้หลายประเทศ (ที่มีระบบ OLTP แตกต่างกัน) สิ่งที่สำคัญที่สุดคือมาตรฐานของนิยามข้อมูล หรือ data definition standard ที่มีความจำเป็นจะต้องสอดคล้องกัน ไม่อย่างนั้น จะก่อให้เกิดปัญหาตามมามากมาย ผมยกตัวอย่างคำถามเกี่ยวกับนิยามของข้อมูลอย่างเช่น

ปริมาณสินค้าคงคลังที่ตัวแทนจำหน่าย (inventory หรือบางทีก็เรียก stock)

• เริ่มต้นนับจากเมื่อใดที่ตัวแทนจำหน่ายเป็น “เจ้าของ” สินค้านั้น ในบางพื้นที่ที่การขนส่งใช้เวลานาน การส่งสินค้าออกจากโรงงานต้นทาง ไปจนถึงคลังสินค้าของตัวแทนจำหน่ายอาจใช้เวลาถึง 5 วัน สมมติว่าส่งสินค้า 100 ลัง เจ้าสินค้า 100 ลังนี้ จะถูกนับว่าเป็น inventory ของบริษัท หรือเป็นของตัวแทนจำหน่าย ในช่วงเวลา 5 วันนี้?
• สินค้า “แถม” หรือสินค้าโปรโมชั่นที่มีการรวมเอาผลิตภัณฑ์อย่างอื่นไปด้วย ไม่ได้นับเป็นยอดขาย แต่จะนับรวมอยู่ในยอดสินค้าคงคลังด้วยหรือไม่?
• สินค้าเก่า, เสียหายเนื่องจากการขนส่ง, หรือกำลังจะหมดอายุ (นำไปขายต่อไม่ได้แล้ว) ถูกนับรวมอยู่ในยอดสินค้าคงคลังด้วยหรือไม่?
• การคำนวณมูลค่าของสินค้าคงคลัง ใช้วิธีใด ระหว่าง LIFO, FIFO หรือจะใช้ปริมาณคูณกับต้นทุนมาตรฐาน?
• การคำนวณ Days of Supply หรือ Days On Hand (ซึ่งเป็นตัวชี้วัดอย่างหนึ่งที่บอกว่า ถ้าไม่มีการสั่งสินค้ามาเพิ่มเติม ปริมาณสินค้าคงคลังที่มีอยู่ จะสามารถขายได้ประมาณกี่วัน) ใช้สูตรอะไรในการคำนวณ?

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

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

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

• กระบวนการทำงานที่อาจต้องปรับเปลี่ยน
• วิธีการบันทึกข้อมูล
• การประมวลผล, จัดเก็บข้อมูลใน OLTP, รวมถึงการ extract ข้อมูลออกมาด้วย
• การเปลี่ยน “ความเคยชิน” ในการใช้ข้อมูล ถ้านิยามของข้อมูลเปลี่ยนแปลงไป

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

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

ผมยังไม่เคยเห็น software ที่ใช้ “เลือก supplier” โดยเฉพาะนะครับ มีแต่ที่ใช้ในการช่วยจัดการบริหารความสัมพันธ์กับ supplier (supplier relationship management) ซึ่งมีลักษณะคล้ายๆ เป็น ERP ในระบบ ERP เองโดยทั่วไปก็มีส่วนนี้อยู่แล้ว โดยมักจะอยู่ในส่วนโปรแกรมจัดซื้อ

เมื่อวานนี้คุยเรื่องความแตกต่างระหว่าง business requirement กับ system requirement มาเช้านี้ไปเจอบทความนี้เข้า The Need to Simplify Data and Reporting ซึ่งก็สอดคล้องกับที่คิดไว้เหมือนกัน โดยเฉพาะอย่างยิ่ง ประเด็นที่ว่า 80% ก็ดีพอแล้ว ซึ่งอันนี้เห็นด้วยอย่างยิ่งเลย

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

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

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

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

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

• ข้อมูลเกี่ยวกับบัญชีที่มีความจำเป็นต้องถูกต้องตามที่กฎหมายกำหนด
• ข้อมูลที่เกี่ยวข้องกับธุรกรรมทางการเงิน
• ข้อมูลที่จะถือว่าเป็นหลักฐานอย่างเป็นทางการ

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

ระบบงานไอทีใดๆ ต่างก็ถูกสร้างขึ้นมาเพื่อตอบสนองความต้องการบางอย่างเป็นพื้นฐานอยู่แล้ว ไม่เว้นแม้แต่ระบบ 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 นั่นเอง

Microsoft SQL Azure เป็นหนึ่งในแพลตฟอร์ม Windows Azure จากไมโครซอฟต์ (Azure คืออะไร?) ตอนนี้เปิดให้ลงทะเบียนทดลองใช้ได้ฟรีแล้ว โดยยังเป็นเวอร์ชัน CTP (Community Technical Preview) อยู่ ใครสนใจก็ลองใช้ดูนะครับ

ในบริษัทขนาดใหญ่ กิจกรรมอย่างหนึ่งที่เสมอขึ้นบ่อยๆ เพื่อกระตุ้นการเติบโต คือการซื้อกิจการ (acquisition) หรือการควบรวมกิจการ (merger) เหตุผลทางธุรกิจก็มีมากมายหลากหลายกันไป แต่สิ่งหนึ่งที่มักจะตามมาเสมอ คือการผนวกรวมระบบ IT ของสององค์กรเข้าด้วยกัน ไล่ไปตั้งแต่ระบบพื้นฐาน อย่างเน็ตเวิร์ค โทรศัพท์ อีเมล์ ขึ้นไปจนถึงระบบที่รองรับกระบวนการทำงานพื้นฐาน อย่าง ERP, SCM, CRM  และแน่นอนระบบ Business Intelligence ทั้งหลาย เริ่มตั้งแต่รายงานยอดขายพื้นฐาน ไปจนถึงระบบที่ซับซ้อนอย่างจำพวก Dashboard หรือ BPM

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

The show must goes on
แน่นอนที่สุดว่า กิจการใดๆ จำเป็นที่จะต้องดำเนินธุรกิจต่อไปได้ในช่วงเวลาระหว่างการควบรวมกิจการ ไม่ใช่ประกาศวันนี้ พรุ่งนี้หยุดบริษัทไป 6 เดือนรอจนควบรวมกิจการเสร็จค่อยเปิดทำการต่อ คงได้เจ๊งกันเป็นแถว ดังนั้นประเด็นแรกสุดคือการดูแลให้ธุรกิจสามารถเดินต่อไปได้ จะว่าง่ายก็ง่าย แต่บางทีก็ลำบากเหมือนกัน เพราะหลายครั้งที่พอประกาศซื้อกิจการปุ๊บ ลดพนักงานทันที หรือไม่ก็พนักงานลาออกเอง จึงมีความเป็นไปได้มาก ที่คนที่ดูแลระบบ BI เดิมจะอยู่ในกลุ่มนั้นด้วย ต้องรีบเก็บเกี่ยวความรู้กับพวก document ต่างๆ เอาไว้ให้ได้มากที่สุด จะได้รู้ว่าระบบที่กำลังทำอยู่นั้น หมกอะไรไว้แค่ไหนบ้างหรือไม่

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

Seek first to understand
พอเริ่มตั้งหลักได้ สิ่งที่ควรทำอย่างยิ่งอย่างหนึ่งเลยคือการนั่งพูดคุยกับผู้บริหารทางฝั่งของธุรกิจ เพื่อทำความเข้าใจก่อนว่า กิจการหลังการควบรวมนั้น จะเดินหน้าต่อไปอย่างไร บริษัทจะรวมกันมั้ย (ทางกฎหมาย) หรือจะยังแยกเป็นสองหน่วยธุรกิจ ไลน์สินค้าจะมีการเปลี่ยนแปลงหรือไม่ โครงสร้างองค์กรจะเปลี่ยนไปอย่างไร ช่องทางการจัดจำหน่าย กลยุทธ์ทางการตลาดและการดูแลลูกค้าจะปรับเปลี่ยนไปแค่ไหน แนวทางเหล่านี้ส่วนใหญ่ผู้บริหารระดับสูงคิดเอาไว้แล้วแหละ เพียงแต่อาจจะไม่ได้ประกาศออกไปเป็นวงกว้างในองค์กร และโดยมากก็มักจะมีการวางแผนกันเป็นระยะเวลายาว 2-3-4 ปีจนกว่าการควบรวมจะสมบูรณ์ มีการแบ่งออกเป็นเฟสต่างๆ เพื่อให้การเปลี่ยนแปลงเป็นไปแบบค่อยเป็นค่อยไป ในระดับที่เจ้าหน้าที่ในองค์กรสามารถปรับตัวได้ทัน

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

การเข้าใจแผนงาน และแนวทางการดำเนินธุรกิจหลังการควบรวม จะทำให้เราสามารถวางแผนงานด้าน IT และด้าน BI ได้สอดคล้องกับแนวทางเหล่านั้นได้มากขึ้น และมีเวลาเตรียมความพร้อมของระบบเพื่อสนับสนุนเฟสต่างๆ ของการรวมกิจการ

Plan and execute
พอเข้าใจกรอบแนวทางของธุรกิจแล้ว ก็ย้อนกลับมาดูด้านระบบ BI บ้าง เอาแผนธุรกิจวางไว้เป็นกรอบ แล้วก็วางแผนย้อนหลังกลับมา ถ้าจะมีการปรับเปลี่ยนแนวทางการดำเนินธุรกิจในอีก 2 ปีข้างหน้า (หลังการควบรวม) ระบบ BI ที่จะสนับสนุนงานนั้น ต้องมีลักษณะอย่างไรบ้าง เราจะได้รูป future state คร่าวๆ แล้วก็มาพิจารณาเปรียบเทียบกับความสามารถในปัจจุบัน ของทั้งสองบริษัท ร่างรายการออกมาว่ามีอะไรจะต้องปรับเปลี่ยนบ้าง ส่วนไหนที่ซ้ำซ้อน ส่วนไหนที่เป็นปัญหาต้องแก้ไข อะไรที่ยังขาดอยู่และต้องพัฒนาเพิ่มเติม ร่างรายการเหล่านี้เสร็จ เราก็ได้ transition plan พอดี ขั้นต่อไปก็ไปหาเงินมาทำงานตามแผนงานนั้น (พูดเหมือนง่าย แต่ความจริงยากกว่าส่วนอื่นๆ อีก)

กระบวนการเหล่านี้ใช้เวลานะครับ หลายเดือน จนเป็นปี อย่าด่วนหักโหม แบบประเภทซื้อบริษัทใหม่เข้ามา โยน BI ของบริษัทใหม่ทิ้งไปให้หมด เอาระบบของเราไปให้เขาใช้ user อาจจะไฟธาตุแตกเอาได้ง่ายๆ แถมยังเสียโอกาสที่จะได้ปรับปรุงระบบของเราให้ดีขึ้นอีกด้วย

แต่ละปีพอถึงเวลาต้องวางแผน ว่าจะทำโปรเจ็คไอทีอะไรบ้าง เรื่องที่ชวนปวดหัวอยู่เป็นประจำก็คือ จะเลือกโปรเจ็คอย่างไรดี คนที่ดูแลแผนงาน IT คงเคยพบว่า ฝ่ายขายก็ขอให้ทำไอ้นั่น มาร์เก็ตติ้งต้องการไอ้นี่  CEO อยากให้มีระบบนี้ แถมยังเจอประเภทประกาศกรมสรรพากร ประกาศกระทรวงแรงงาน หรือไอซีที บังคับว่าระบบคอมพิวเตอร์ในบริษัทต้องมีลักษณะตามนี้ๆๆๆ ไม่ทำตามเจอปรับ บางทีก็เจอไฟล์ทบังคับ ไม่ได้อยากทำเล้ย แต่ก็ต้องหาเงินมา upgrade ระบบเพราะพ่อเจ้าประคุณ Microsoft, Oracle, SAP และอื่นๆ เกิดไม่ซัพพอร์ทเวอร์ชั่นเก่าๆ ขึ้นมาเสียเฉยๆ ถ้าไม่ upgrade เดี๋ยวมีปัญหาขึ้นมา หาคนมา patch ให้ไม่ได้เสียอีก

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

หลักการนี้ผมเรียกกันสั้นๆ ว่า FFA ย่อมาจาก Fit, Feasibility, and Attractiveness ก็เป็นวิธีง่ายๆ ในการให้คะแนนข้อเสนอโครงการแต่ละข้อ ตามหลักเกณฑ์ FFA โปรเจ็คไหน ได้คะแนนสูง ก็ทำโปรเจ็คพวกนั้นก่อน เงินกับคนหมดเมือไหร่ ก็ขีดเส้นหยุดพอได้ เกณฑ์การให้คะแนนแต่ละข้อก็ให้เท่าๆ กัน เอาเป็นว่าสเกล 1-5 ก็แล้วกัน คือ คะแนนสูงสุดคือ 5 คะแนนในแต่ละหัวข้อของ FFA ดังนั้นคะแนนเต็มคือ 15 คะแนน

ลองมาดูกันบ้างว่า FFA แต่ละตัวหมายถึงอะไรบ้าง

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

Feasibility : ความเป็นไปได้ทั้งทางด้านเทคนิคและทางเศรษฐศาสตร์
คะแนนสำหรับ feasibility นี่จะให้สำหรับโครงการที่เชื่อว่า “เป็นไปได้” หรือมีข้อพิสูจน์แล้วว่า ทำได้ หรือเป็นไปได้ ยิ่งถ้าเคยทำมาก่อนแล้วนี่คะแนน feasibility นี่ให้ 5 ไปเลย แต่ถ้าเป็นอะไรที่ เจ๋งสุดๆ ทำเป็นเจ้าแรกในโลกเลย อันนี้เอาคะแนนต่ำๆ ไปเพราะความเสี่ยงสูง ความเป็นไปได้นี่ไม่ได้เฉพาะแค่เรื่องทางเทคนิคนะครับ แต่รวมถึงเรื่องความเป็นไปได้ทางการเงินด้วย

Attractiveness : ความน่าสนใจ (จากฝั่งธุรกิจ)
หรือบางทีอาจจะเรียกว่า cool factor ก็ได้ บางโปรเจ็คอาจจะมีความน่าสนใจสูง ถ้ามันสอดคล้องกับวิสัยทัศน์ของธุรกิจ หรือสามารถให้ผลตอบแทนได้สูง ไม่ว่าจะเป็นในรูปของ ROI หรือในรูปของ productivity gain ของพนักงาน แต่ข้อนี้คนที่ให้คะแนนควรจะเป็นคนขอโครงการ เพราะแต่ละคนเห็นความน่าสนใจของแต่ละโครงการไม่เท่ากัน

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