GAP Analysis

เมื่อหลายวันก่อน ผมได้พูดทิ้งค้างเอาไว้ในหัวข้อการสร้างซอฟต์แวร์ระดับ Enterprise เอาไว้ ดังนั้นเลยคิดว่าวันนี้มาต่อกันดีกว่า

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

ทีนี้สิ่งที่ถูกต้องคืออะไรล่ะ???

นักพัฒนาซอฟต์แวร์อย่างเราซึ่งทำงานอยู่ในองค์กรนั้น ๆ ก็ต้องมาวางแผนที่จะเชื่อมมันเข้าหากันไงครับ โดยศัพท์ทางเทคนิคเราเรียกว่าการทำ GAP Analysis

GAP Analysis ถ้าแปลอย่างง่าย ๆ ก็จะแปลว่า การวิเคราะห์ช่องว่าง ซึ่งมันก็เป็นอย่างนั้นจริง ๆ ส่วนหนึ่ง แต่ส่วนขยายที่เพิ่มเติมน่าจะหมายถึง การวิเคราะห์ถึงช่องว่าง, สิ่งที่ขาดหายไปที่ควรเติมเต็ม และสิ่งนั้นจะต้องเป็นไปได้ที่จะทำด้วย

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

จากนั้นทีมงานวิเคราะห์ก็จะเริ่มปรึกษาหารือกันครับ ว่าระบบใดควรจะเชื่อมกับระบบใดบ้าง ยกตัวอย่างเช่น

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

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

• Project Manager คนนี้จะนั่งเป็นประธานครับ คอยอนุมัติหรือไม่อนุมัติ ถือเป็นผู้ชี้ขาดในห้องประชุมเลยทีเดียว
• Project Co-Ordinator จะมีมากกว่าหนึ่งคนครับ มีทั้งคนขององค์กรเราเอง และคนของบริษัทเอกชนที่สร้างระบบให้เรา อย่างในตัวอย่างมี 3 ระบบที่ต้องทำงานร่วมกัน ดังนั้น Project Co-Orinator อาจจะมีถึง 4 คน โดยมาจากบริษัทเอกชน 3 จ้าว และขององค์กรเราเองอีก 1 คน
• System Analyst มีเพียบครับ จะมีหลายคนเลยที่จะต้องมาช่วยวิเคราะห์ความเป็นไปได้ของระบบกัน อย่างถ้ามี 3 ระบบแบบนี้เชื่อมกัน ก็จะมีประมาณ 4-5 คนได้
• Key User หมายถึง ผู้ที่เป็นบุคลากรหลักในหมู่คนใช้ระบบครับ พวกนี้จะลงลึกถึงรายละเอียดของระบบที่ตนเองนั้นทำงานอยู่ ถือเป็นคนทำงานในระบบครับ คนเหล่านี้ส่วนใหญ่จะเป็นระดับหัวหน้าแผนก หรือผู้จัดการฝ่ายของระบบนั้น ๆ ครับ

ก็จะคุยกันไปครับถกกันวุ่นวายเลยทีเดียว คนระดับพวกนี้ถือว่าเป็นพวกที่รู้ธุรกิจกับระบบอย่างที่เคยบอกเอาไว้ครับ จะเห็นว่าในวงประชุมดังกล่าว ไม่มีคนรู้เทคนิคมาพูดมาคุยด้วยเลย

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

และเอกสารที่เรียกว่า Functional Specification เพื่อเอาไว้อธิบายโปรแกรมเมอร์และวิศวกรซอฟต์แวร์ว่า ระบบแต่ล่ะระบบจะแลกเปลี่ยนข้อมูลอะไรบ้าง, เป็นข้อมูลประเภทอะไร และจะแลกเปลี่ยนกันตามจังหวะเวลาใด ๆ บ้าง

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

การพัฒนาซอฟต์แวร์ระดับ Enterprise จะทำไม่ได้ครับ ถ้าขาดซึ่ง Context Diagram และ Functional Specification ครับ ต่อให้เราเป็นนักพัฒนาซอฟต์แวร์หรือโปรแกรมเมอร์ที่เก่งแค่ไหนก็ทำไม่ได้ครับ เพราะผมเคยลองแล้ว มันทำไม่ได้ครับ มันจำไม่ได้ รายละเอียดมันเยอะ