ข้อมูลต่อไปนี้ได้นำมาจากคำตอบข้อสอบปลายภาค ภาควิชาเทคโนโลยีการจัดการสารสนเทศ นำมา Post ซ้ำเผื่อไว้ให้ผู้อ่านในภาษาไทยลองดูเผื่อรุ่นน้องๆที่เรียนอยู่จะนำไปใช้ประโยชน์ในการคิดวิเคราะห์ได้
สาเหตุที่ทำให้ London Ambulance Service ล้มเหลว
1.1 System Design
ปี 1987-1990 ที่เกิดจากการเปลี่ยนแปลง specification ต่างๆ จนกระทั่งก่อปัญหาให้การพัฒนามีความซับซ้อนมากยิ่งขึ้น ส่งผลให้มูลค่า และ การใช้เวลาการพัฒนาระบบสูงขึ้นด้วย ซึ่งสร้างค่าใช้จ่ายที่เกิดขึ้นมีมูลค่ารวมทั้งสิ้น 11.25 M$
ปี 1991 การออกแบบระบบของ LAS เป็นการหยิบใช้ Process การทำงานที่มีอยู่เดิมแต่ประยุกต์การทำ Automate เข้าไป และ Re-use และสิ่งที่สำคัญที่สุดคือ ไม่มีรายงานถึงข้อกำหนดเชิงคุณภาพ (Qualitative requirement) ในรูปแบบใดๆ ที่จะกำหนดว่า ระบบควรจะทำงานได้มากน้อยเพียงใด
1.2 Procurement process
การจัดซื้อโดยการประมูลราคาเป็นทางเลือกที่เหมาะสม แต่ปัญหาที่เกิดขึ้นเนื่องจาก การจัดซื้อผ่าน System options ที่ตรวจสอบพบ มีราคาที่ต่ำกว่าผู้ประมูลรายอื่นอย่างผิดสังเกต และไม่มีบันทึกในการประชุมในการตรวจสอบรายการ หรือ หารือถึงสาเหตุของปัญหาเรื่องราคานั้นต่ำผิดปกติเกินไปหรือไม่ (โดยการประเมิน ราคาระบบที่เหมาะสมควรอยู่ที่ £1.5 M แต่ราคาที่ประมูลได้ต่ำกว่านั้นถึง 1 ใน 3 ของราคาประเมิน)
1.3 Timetable
แม้จะไม่มีการรายงานเรื่องกำหนดเวลาอย่างชัดเจน แต่ในช่วงเดือนตุลาคม 1991 ที่มีเอกสาร PIR (Project Issue Report) เป็นจุดที่ระบุถึงการทำ Implementation ในขณะนั้น แต่การ Implement กำหนดให้ทำงานในงานทั้งสิ้น 3 Phrase โดยไม่มีการแบ่งแยกช่วงการทำงานหรือการทดสอบใดๆ (ภายหลังตรวจสอบพบว่า sub-system มีหลายส่วนที่ทดสอบน้อย หรือ ไม่ได้ทำการทดสอบเลย) จนถึงกำหนดเวลาสิ้นสุดช่วงเดือนตุลาคม 1992 ระบบได้ดำเนินการได้จนถึง Phrase 3 (ซึ่งกำหนดเป็น Phrase สุดท้าย) โดยยังมีปัญหาระดับย่อยๆที่ยังไม่ได้แก้ไขอยู่บางรายการ ก่อนที่จะตัดสินใจให้ใช้ระบบแบบ Hybrid ดำเนินงานจริงในวันที่ 26 ตุลาคม 1992 คือ การใช้ CAD + Allocators (คน) + Activation box
1.4 Testing
การทดสอบย่อยที่เริ่มในช่วงเดือนมกราคม 1992 ที่มีการทำ Load test ขององค์ประกอบย่อยหลายส่วน แต่ข้อสรุปนั้นจบอยู่ที่ ไม่มีหลักฐานใดๆที่อ้างอิงถึงการทำการทดสอบตาม requirement (functional testing), การทดสอบรวมทั้งระบบ (Integration testing), และ การทดสอบ Load testing ด้วยความบกพร่องนี้ จึงทำให้ไม่มีใครคาดเดาได้เลยว่า หากระบบนี้ทำงานไปในสภาพแวดล้อมจริง จะส่งผลในลักษณะใด
1.5 Quality Assurance
การทำ Quality assurance ได้กำหนดไว้ในแบบร่างโครงการ (Project proposal) ให้บริษัท Consult ต่างรายทำหน้าที่ในการตรวจสอบคุณภาพของ Software ที่ได้จัดทำขึ้น แต่การเปลี่ยนแปลงของ System Manager ทำให้นโยบายของการทำ QA เปลี่ยนไปโดยกำหนดให้ System Options ทำการทดสอบคุณภาพของ Software เอง เพื่อหลีกเลี่ยงค่าใช้จ่ายที่จะเกิดขึ้น
1.6 Training
การ Training ที่วางแผนไว้จากเดิม ณ วันที่โครงการแรกจะดำเนินการทดลองใช้ไม่สามารถทำได้ตามกำหนด ปัญหาของระบบที่ยังไม่สามารถนำมาใช้งานได้อย่างสมบูรณ์ รวมไปถึงการเปลี่ยนแปลงโครงสร้างการทำงานไปจากเดิมของระบบเดิม, และระบบที่ออกแบบครั้งที่ 1 ที่ล้มเหลวจึงทำให้พนักงานเกิดความไม่พอใจที่ได้รับการฝึกฝนในระยะเวลาที่น้อยเกินไปมาก ทั้งนี้ ยังไม่รวมถึงปัญหาด้านการจัดการบริหารบุคคล และการควบคุมข้อพิพาทในเรื่องการต่อต้านการใช้งานระบบใหม่ ของพนักงานฝ่ายยานพาหนะกู้ภัย (Ambulance staff)
1.7 Project Management
ด้วยงานที่ไม่มีบุคลากรที่ทำงานแบบเต็มเวลา เป็นข้อผิดพลาดในการจัดการบริหารงานด้านบุคคล เพราะงานที่ดำเนินการ จะขาดความต่อเนื่อง
อย่างไรก็ดี มีความพยายามที่จะนำมาตรฐานการทำ Project โดย PRINCE methodology มาใช้ แต่ด้วยปัญหาด้านบุคลากรที่ไม่มีประสบการณ์เรื่องนี้เลย ก็ทำให้การนำเอาหลักการควบคุมนี้มาใช้ ไม่เกิดประโยชน์แต่อย่างใด
อีกทั้งการเปลี่ยนแปลงนโยบายที่สำคัญๆหลายอย่าง เช่น การริเริ่มใช้ PIR ก่อนที่จะมีการเปลี่ยนผู้ควบคุมโครงการในเดือนตุลาคม 1991 ที่จะย้ายการทำเอกสาร PIR ไปอยู่กับ Project team และย้ายการทำ QA ไปอยู่กับ Project team เช่นกัน
นอกจากนั้น พนักงานที่ปฏิบัติหน้าที่ในแผนกต่างๆ ไม่มีความมั่นใจในระบบใหม่ โดยอ้างอิงจากผลการสำรวจความคิดเห็นในเดือนมกราคม 1992 ซึ่งส่งผลกระทบโดยตรงทั้งในด้านการทำ Training, การควบคุมระเบียบวินัย, ทัศนคติในการทำงานกับระบบ และเป็นอีกส่วนหนึ่งที่ทำให้โครงการล้มเหลวได้ นอกเหนือจากปัญหาด้านเครื่องมือ และคุณภาพของ Software
คำแนะนำในการแก้ไขข้อผิดพลาดของสาเหตุดังกล่าว
2.1 System Design
ในการเริ่มต้นทำโครงการ ผู้ออกแบบควรยึดกระบวนการตามหลักการพัฒนา Software ที่ถูกต้องก่อน เช่น เริ่มจากการพิจารณาความเป็นไปได้ในการดำเนินการ, วิเคราะห์ความต้องการของผู้ใช้, ออกแบบสถาปัตยกรรมระบบและ System specification ที่เหมาะสม
การจัดวางตัวบุคคลที่รับผิดชอบโครงการในระยะแรก ต้องมีความเหมาะสม และสามารถรับผิดชอบดูแลบุคคลที่เกี่ยวข้องโดยรวมด้วย เช่น พนักงาน, System analysis, หรือ Consultant เป็นต้น
2.2 Procurement process
การจัดซื้อในหมวดของสินค้า หรือ การจัดหา System integrator ที่เหมาะสม จะต้องมีการจัดประมูลโครงการที่โปร่งใส, ตัวโครงการต้องมีข้อจำกัดที่ชัดเจนโดยการทำ TOR (Term of Reference), มีคณะบุคคลที่ทำหน้าที่ตรวจสอบคุณภาพของสินค้า หรือ ประสบการณ์ของบุคคลที่จะจัดจ้างเข้ามาทำงานที่ต้องมีความเหมาะสม มีมูลค่าที่ไม่ต่างจากราคาประเมินมาก หรือน้อยจนเกินไป
2.3 Timetable
เวลาในการดำเนินการระบบ ควรจะถูกจัดวางในวันที่ดำเนินการวิเคราะห์ถึงความเป็นไปได้ (ขั้นตอนแรก), ในการประมาณเวลาในการพัฒนาระบบ จะต้องมีระยะเวลาที่เหมาะสม โดยอาจจะเปิดโอกาสให้ผู้พัฒนาระบบ, นักวิเคราะห์ระบบ ประชุมร่วมกับผู้ดูแลการจัดการบริหารโครงการ เพื่อหาข้อสรุปเกี่ยวกับความเสี่ยงในด้านการจัดการเวลาในการจัดทำระบบ ซึ่งจะช่วยให้การกำหนดระยะเวลาในการจัดทำโครงการมีความแม่นยำ และดูสมเหตุสมผล
2.4 Testing
การทดสอบระบบ ต้องทำการวางแผนการทดสอบระบบอย่างเป็นขั้นตอน และไม่ซ้ำซ้อน ทั้งนี้ อาจจะให้นักวิเคราะห์ระบบ ประเมินความเหมาะสมในเรื่องของระยะเวลา และวิธีการทำการทดสอบ เช่น การทดสอบแบบ White-box หรือ Black-box, การทดสอบ functional testing เพื่อหาข้อบกพร่องย่อย, การทดสอบ Integration test และการทดสอบ Load test การทดสอบในแต่ละขั้นตอน จะต้องมีเอกสารเกี่ยวกับการทำทดสอบที่ชัดเจน รวมไปถึง การทำทดสอบที่มีประสิทธิภาพและถูกต้องนั้น จะช่วยให้กระบวนการทำ Acceptance test หรือ นำระบบไปใช้งานจริง จะมีความง่ายมากขึ้น
2.5 Quality Assurance
กรณีที่ต้องการทำการทดสอบคุณภาพของ Software จะต้องมีกลุ่มผู้ทดสอบคุณภาพการทำงานของ Software มาดำเนินการในส่วนนี้ต่างหาก ไม่ควรที่จะให้นักวิเคราะห์ระบบ หรือ กลุ่มผู้พัฒนาระบบ ทำหน้าที่วางรูปแบบการประเมินผลคุณภาพของ Software ด้วยตนเอง
2.6 Training
ระบบการให้ความรู้ของพนักงาน ถือว่าเป็นภาระที่มีความยุ่งยากอย่างหนึ่งในการทำระบบ ดังนั้น ควรจะจัดเจ้าหน้าที่ที่สามารถนำเสนอภาพรวมของระบบ ในมุมมองของผู้ใช้งานที่ชัดเจน และดึงดูดให้พนักงานส่วนใหญ่เห็นข้อดีของการจัดทำระบบใหม่ ทั้งนี้ การให้ความรู้กับพนักงานที่มีหน้าที่ในการปฏิบัติงานนั้น ควรจะร่วมมือกับงานทรัพยากรบุคคลโดยเฉพาะ เพื่อให้ผลลัพธ์ของการจัดระบบการเรียนการสอน หรือฝึกฝนการใช้งานมีประสิทธิภาพสูงสุด และเกิดการต่อต้านระบบใหม่น้อยที่สุด
2.7 Project Management
การควบคุมจัดการบริหารโครงการ ควรจะใช้กระบวนการจัดการที่เหมาะสม ณ ขณะนั้น ในกรณีที่โครงการมีความซับซ้อน หรือมีขนาดใหญ่มาก การจัดการตามมาตรฐานที่เหมาะสมจะช่วยเพิ่มความรัดกุมมากกว่า เช่น การใช้ PRINCE ณ เวลานั้น หรือ ในปัจจุบัน ควรจะจ้าง System integrator ที่ผ่านมาตรฐานการทำงาน หรือผ่านการทดสอบมาตรฐาน CMM เป็นต้น
บุคลากรที่ทำงานในส่วนที่สำคัญ ควรจะมีความรู้ในการทำงาน และเข้าใจถึงปัจจัยเสี่ยงต่อการล้มเหลวของโครงการเป็นอย่างดี ทำงานในระยะเวลาที่เหมาะสม ไม่ควรจะมีการโยกย้าย หรือเปลี่ยนตำแหน่งของบุคคลที่ทำหน้าที่สำคัญในโครงการ ซึ่งจะช่วยป้องกันความล้มเหลวได้ดีมากขึ้น
From Tiwakorn Laophulsuk Final Examination Answer Paper
May 2008
