อุปมากลุ่มหนึ่งมักได้ผลดีกว่าการพูดตรงๆ ดังนั้นขอเริ่มด้วยอุปมาเรื่องหนึ่ง ชายคนหนึ่งไปดูการก่อสร้างมหาวิหาร เขาถามช่างหินว่ากำลังกระเทาะหินทำอะไร ช่างตอบว่า “ฉันกำลังทำหิน” เขาถามช่างแกะสลักว่ากำลังทำอะไร ช่างตอบว่า “ฉันกำลังแกะสลักรูปปั้นประหลาด” ไปเรื่อยๆ แต่ละคนบอกรายละเอียดสิ่งที่ตนทำ สุดท้ายเขาพบหญิงชราที่กวาดพื้น เธอตอบว่า “ฉันกำลังช่วยสร้างมหาวิหาร”
ถ้าคุณสุ่มถามอาจารย์ในมหาวิทยาลัยทั่วไปว่าพวกเขาจะทำอะไรในชั่วโมงเรียนถัดไป คุณจะได้ยินคำตอบอย่าง “สอนการแยกเศษส่วน” “สาธิตการหาค่ามอมเมนต์ของการแจกแจงแบบปกติ” “อธิบาย Young’s modulus และวิธีการวัด” เป็นต้น ผมคิดว่าไม่ค่อยมีอาจารย์คนไหนตอบว่า “ฉันจะให้การศึกษาแก่นักศึกษาและเตรียมพวกเขาสำหรับอาชีพในอนาคต”
คุณอาจจะบอกว่าจุดประสงค์ที่ใหญ่กว่าในทั้งสองกรณีนั้นชัดเจนอยู่แล้วจึงไม่ต้องพูด แต่ผมไม่แน่ใจว่าคุณเชื่อแบบนั้นจริงๆ ส่วนใหญ่คนมักจมอยู่กับรายละเอียดของส่วนเล็กๆ ที่ตนรับผิดชอบ และไม่คิดเลยว่าสิ่งที่ทำเกี่ยวข้องกับภาพรวมอย่างไร คนทั่วไปมักมองงานแบบมองไม่ไกลและแทบไม่เคยเชื่อมสิ่งที่ทำกับเป้าหมายใหญ่ที่พวกเขายอมรับเมื่อตกอยู่ภายใต้การกดดัน ทัศนคติมองแคบนี้เป็นลักษณะหลักของข้าราชการ ถ้าคุณอยากขึ้นไปถึงตำแหน่งสูงสุด คุณควรมองภาพรวม—อย่างน้อยก็เมื่อคุณไปถึงจุดนั้น
Systems engineering คือความพยายามที่จะคงเป้าหมายในภาพรวมไว้ ตลอดเวลา และแปลงการกระทำท้องถิ่นให้เป็นผลลัพธ์ระดับระบบ แต่ไม่มีภาพใหญ่เดียวที่เป็นสากล ตัวอย่างเช่น เมื่อครั้งแรกที่ผมมีคอมพิวเตอร์อยู่ภายใต้การควบคุมทั้งหมด ผมคิดว่าเป้าหมายคือให้เครื่องทำการคำนวณให้ได้จำนวนการดำเนินการมากที่สุดต่อวัน ไม่นานผมก็เข้าใจว่าสิ่งที่สำคัญไม่ใช่ปริมาณดิบ แต่เป็นปริมาณของ การคำนวณที่มีคุณค่า ต่อมา ผมเห็นว่าที่สำคัญไม่ใช่การคำนวณของภาควิชาคณิตศาสตร์ที่ผมอยู่ แต่ว่าการคำนวณของหน่วยวิจัยที่สำคัญ จริงๆ ผมตระหนักว่าหากจะให้ได้คุณค่ามากที่สุดจากเครื่องใหม่ จำเป็นต้องให้บรรดานักวิทยาศาสตร์ใช้เครื่องโดยตรง เพื่อให้พวกเขาเข้าใจศักยภาพที่คอมพิวเตอร์มอบให้กับงานของพวกเขา และด้วยเหตุนี้งานคำนวณเชิงตัวเลขจริงอาจลดลง แต่การคำนวณที่ทำจะมีคุณค่าสำหรับ Bell Telephone Laboratories มากขึ้น ต่อมาอีกผมเห็นว่าต้องใส่ใจความต้องการทั้งของ the Laboratories ไม่ใช่แค่แผนกวิจัย จากนั้นยังมี at&t และนอกเหนือจาก at&t ก็มีประเทศ ชุมชนนักวิทยาศาสตร์และวิศวกร และจริงๆ แล้วโลกทั้งใบที่ต้องถูกพิจารณา ดังนั้นผมมีพันธะต่อทั้งตัวเอง ต่อแผนก ต่อหน่วย ต่อบริษัท ต่อบริษัทแม่ ต่อประเทศ ต่อชุมชนนักวิทยาศาสตร์และวิศวกร และต่อทุกคน ผมไม่สามารถขีดเส้นแบ่งชัดเจนแล้วเพิกเฉยต่อสิ่งภายนอกได้
พันธะในแต่ละกรณีประกอบด้วย (1) ความสำคัญในทันที (2) ความสำคัญในระยะยาว และ (3) ความสำคัญในระยะยาวมาก ผมยังตระหนักด้วยว่า ภายใต้ข้อ (2) และ (3) หนึ่งในหน้าที่ของผมในแผนกวิจัยไม่ได้เน้นการแก้ปัญหาเดิมๆ เท่านั้น แต่เป็นการพัฒนาวิธีการแก้ปัญหา ขยายขอบเขตของสิ่งที่ทำได้ และสอนผู้อื่นในสิ่งที่ผมค้นพบ เพื่อให้พวกเขาสามารถสานต่อ ขยาย และปรับปรุงผลงานของผมได้ต่อไป
ในการทำ systems engineering พูดคำถูกต้องง่าย แต่ทำจริงยาก เช่นเดียวกับกีฬาอย่างเทนนิส กอล์ฟ หรือว่ายน้ำ หลายคนพูดได้ดีเมื่อถูกถามเรื่อง systems engineering แต่การทำให้เป็นระบบทั้งระบบกลับยาก ดังนั้น systems engineers ควรถูกตัดสินไม่ใช่จากสิ่งที่พูด แต่จากสิ่งที่ผลิตออกมา มีคนจำนวนมากที่พูดเก่งแต่ลงมือทำไม่ได้
กฎข้อแรกของ systems engineering คือ:
หากคุณปรับแต่งส่วนประกอบให้เหมาะสมที่สุด คุณมีแนวโน้มที่จะทำให้ประสิทธิภาพของระบบโดยรวมแย่ลง
เรื่องนี้อธิบายยากมาก มันดูสมเหตุสมผล: ถ้าคุณทำให้ส่วนประกอบแยกชิ้นนั้นดีขึ้น ระบบทั้งหมดก็น่าจะดีขึ้น—แต่ความจริงไม่เป็นอย่างนั้น; ประสิทธิภาพของระบบอาจกลับแย่ลง! ยกตัวอย่างง่ายๆ ผมเคยใช้งาน differential analyzer และประสบความสำเร็จในการแก้ปัญหาจนต้องการเครื่องที่ใหญ่ขึ้นและเครื่องที่สอง เราจึงสั่งเครื่องที่สองซึ่งจะต่อกับเครื่องแรกเพื่อให้ทั้งสองทำงานแยกกันหรือรวมกันได้ ทางโรงงานสร้างรุ่นที่สองและอยากปรับปรุงบางอย่าง ผมยอมรับการเปลี่ยนแปลงเฉพาะเมื่อมันไม่รบกวนการทำงานของทั้งระบบ เมื่อถึงวันตรวจรับบนพื้นโรงงานก่อนย้ายมาที่เรา ผมเริ่มทดสอบมันกับเพื่อนที่ไม่ค่อยเต็มใจซึ่งบอกว่าผมกำลังเสียเวลา การทดสอบครั้งแรกล้มเหลวอย่างย่อยยับ! การทดสอบนั้นเป็นแบบคลาสสิกของการแก้สมการเชิงอนุพันธ์
สรุป: whose solution is, of course, y = cos t. You then plot y(t) against y'(t) and you should get a circle. How well it closes on itself, loop after loop, is a measure of the accuracy.
เราลองทดสอบกับส่วนประกอบอื่นๆ ก็ได้ผลเหมือนเดิม เพื่อนผมต้องยอมรับว่ามีบางอย่างผิดปกติอย่างร้ายแรง ดังนั้นเราจึงเรียกผู้ที่สร้างเครื่องมาดูและชี้ให้เห็นข้อบกพร่อง—ซึ่งแสดงให้เห็นได้ง่ายจนพวกเขาต้องยอมรับ เช่นนั้นพวกเขาแกะปรับแต่งอยู่ขณะที่เราดู สุดท้ายผมกับเพื่อนไปกินข้าวกลางวัน พอกลับมาพวกเขาพบปัญหา พวกเขาปรับปรุงแอมพลิไฟเออร์มากขึ้น แต่ตอนนี้กระแสผ่านกราวด์ที่ไม่เพียงพอก่อให้เกิดการรั่วไหลกลับของวงจร! พวกเขาเพียงแค่ใส่สายกราวด์ทองแดงที่หนาขึ้น และทุกอย่างก็กลับมาทำงานได้ดี อย่างที่ผมพูด การปรับปรุงส่วนประกอบในเครื่องเช่นนี้ แม้แต่เมื่อแต่ละชิ้นดูเหมือนยืนได้ด้วยตนเอง ก็ยังสามารถทำให้ประสิทธิภาพของระบบโดยรวมเสื่อมลงได้ นี่เป็นตัวอย่างเรียบง่าย แต่ชี้ให้เห็นประเด็นของกฎ โดยปกติผลของการปรับปรุงชิ้นส่วนจะไม่ชัดเจนหรือเด่นชัดเท่านี้ แต่ก็ยังเป็นอันตรายต่อประสิทธิภาพของระบบโดยรวม
คุณอาจยังไม่เชื่อคำกล่าวนี้ ดังนั้นขอให้ผมยกกฎนี้มาประยุกต์กับพวกคุณ ส่วนใหญ่พยายามผ่านแต่ละวิชาโดยการท่องหนังสือช่วงท้ายเทอม ซึ่งในหลายกรณีกลับให้ผลตรงกันข้าม ตามที่คุณรู้ดีต่อการศึกษาโดยรวม คุณมองปัญหาเป็นการผ่านวิชาเป็นเรื่องๆ หรือเป็นเทอม แต่คุณก็รู้ในใจว่าสิ่งที่สำคัญคือคุณได้อะไรเมื่อสำเร็จการศึกษา ไม่ใช่สิ่งที่เกิดขึ้นในแต่ละช่วง ในสองปีสุดท้ายของผมที่ University of Chicago กฎคือสุดท้ายต้องสอบครั้งเดียวที่อิงจากเก้าหัวข้อในวิชาเอก และอีกครั้งหนึ่งที่อิงจากหกหัวข้อในวิชารอง และนั่นแหละคือสิ่งที่สำคัญ ไม่ใช่เกรดระหว่างทาง สำหรับผมเป็นครั้งแรกที่ได้เข้าใจว่าทัศนคติแบบระบบต่อการศึกษาหมายถึงอะไร ขณะเรียนวิชาใดวิชาหนึ่ง มันไม่ใช่เรื่องของการผ่านหรือทำให้อาจารย์พอใจ แต่มันคือการเรียนให้ได้สิ่งที่ยังจำได้อีกสองปีหรือมากกว่า
อีกตัวอย่างหนึ่งของผลจากการปรับแต่งส่วนประกอบคือการสอนคณิตศาสตร์ระดับพื้นฐานในมหาวิทยาลัย ตลอดหลายปีเราได้ปรับปรุงทั้งคอร์สแคลคูลัสและพีชคณิตเชิงเส้น โดยตัดสิ่งที่ไม่เกี่ยวข้องออกไปทันที ส่งผลให้การสอนคณิตศาสตร์ในภาพรวมมีช่องว่างขนาดใหญ่
- เราแทบไม่กล่าวถึงวิธีที่สำคัญคือการพิสูจน์โดยอุปนัย (mathematical induction)
- หลังจากพูดถึงสั้นๆ ในพีชคณิตเกี่ยวกับสมการกำลังสอง เราแทบไม่พูดถึงจำนวนเชิงซ้อนอีกเลย จนกระทั่งวันอันเลวร้ายในคอร์สเรขาคณิตเชิงเส้น เมื่อ eigenvalues และ eigenfunctions เชิงซ้อนปรากฏขึ้น นักศึกษาต้องเผชิญสองแนวคิดใหม่ที่ยากพร้อมกันและสับสน
- วิธีที่สำคัญและใช้งานได้จริงของ undetermined coefficients ถูกพูดถึงอย่างรวบรัด
- การพิสูจน์ความเป็นไปไม่ได้ (impossibility proofs) แทบถูกเพิกเฉย
- คณิตศาสตร์เชิงดิสครีต (discrete mathematics) ถูกละเลย
- แทบไม่มีความพยายามในการพยายามเปลี่ยนสิ่งที่สำหรับนักศึกษาหลายคนเป็นเพียง “รอยเท้าไก่บนกระดาษ” ให้เป็นแนวคิดที่มีความหมายและนำไปใช้ได้จริง
และเป็นเช่นนี้ ส่วนใหญ่ของการศึกษาคณิตศาสตร์ที่เหมาะสมถูกตัดออกไปในความพยายามปรับแต่งวิชาแต่ละวิชา โดยปกติโครงสร้างภายในของแคลคูลัสและบทบาทศูนย์กลางของลิมิตถูกข้ามไปเพราะถือว่าไม่จำเป็น
การปฏิรูปคอร์สแคลคูลัสที่ผมตรวจสอบหลายกรณีไม่เริ่มด้วยคำถามว่า “การศึกษาคณิตศาสตร์ทั้งหมดคืออะไร และเพราะฉะนั้นอะไรควรอยู่ในคอร์สแคลคูลัส?” พวกเขาเพียงพยายามใส่คอมพิวเตอร์หรือไอเดียบางอย่าง โดยไม่พิจารณาระบบการศึกษาคณิตศาสตร์ทั้งหมดที่คอร์สนี้ควรเป็นส่วนหนึ่ง แนวทางแบบ systems ต่อการศึกษาไม่ได้เติบโตขึ้นจริงๆ ผู้ที่ตื่นเต้นกับแนวคิดต่างๆ มักพยายามปั้นสิ่งให้เข้ากับความกระตือรือร้นท้องถิ่นของตน คำถามว่า “ปัญหารวมที่ส่วนนี้จะเข้าไปอยู่คืออะไร?” ถูกมองว่ายิ่งใหญ่เกินไป ดังนั้นการปรับแต่งย่อยของวิชาจึงดำเนินต่อไป มีคนไม่มากที่เริ่มปฏิรูประบบด้วยการกำหนดปัญหารวมก่อน พวกเขามักโจมตีอาการแรกที่เห็น และแน่นอน สิ่งที่เกิดขึ้นคือสิ่งที่เกิดขึ้น ไม่ใช่สิ่งที่ต้องการ
ผมพยายามคิดถึงประวัติของ systems engineering—และเพียงเพราะระบบถูกสร้างขึ้น มันไม่ได้หมายความว่าผู้สร้างคิดถึงระบบมากกว่าส่วนประกอบ ระบบแรกที่ผมจำรายละเอียดได้คืออาวุธวางเรือของเวนิสในช่วงรุ่งเรืองราว 1200–1400 ที่นั่นมีสายการผลิต และเมื่อเรือลำใหม่เคลื่อนลงสาย เชือก เสากระโดง ผ้าใบ และท้ายที่สุดลูกเรือที่ผ่านการฝึกก็อยู่ตรงนั้นเมื่อจำเป็น เรือลำนั้นก็แล่นออกไป! เป็นสายการผลิตแบบ “just in time” ยุคแรก ซึ่งรวมถึงคนที่ได้รับการฝึกอบรมควบคู่กับอุปกรณ์ที่สร้าง
ทางรถไฟยุคแรกๆ แน่นอนว่าเป็นระบบ แต่ผมไม่แน่ใจว่าผู้สร้างยุคแรกๆ คิดไม่ถึงการปรับแต่งแต่ละส่วนให้เหมาะสมหรือไม่ และไม่ได้คิดจนกระทั่งระบบทั้งหมดเริ่มทำงานว่าเป็นระบบที่ต้องพิจารณา—ว่าชิ้นส่วนจะประสานกันอย่างไรเพื่อให้ระบบทำงานได้ดี
ผมไม่อ้างว่ารู้ว่าผมถูกเปลี่ยนมาเป็น systems engineer ได้อย่างไร ในตอนแรกอาจเริ่มจากการศึกษามหาวิทยาลัย แต่จริงๆ แล้วมันเริ่มขึ้นที่ Los Alamos ซึ่งสำหรับพวกเราทุกคนชัดเจนว่าเรากำลังออกแบบสิ่งที่ทุกส่วนต้องประสานกันอย่างถูกต้องเพื่อให้ทั้งระบบทำงานได้ตามที่ต้องการ—รวมถึงต้องพอดีกับช่องบรรจุระเบิดของเครื่องบินที่ใช้ในขณะนั้น และต้องทำให้เสร็จก่อนฝ่ายศัตรูซึ่งทราบกันว่าก็กำลังพัฒนาเช่นกันจะสำเร็จ
ระบบนำวิถีนำขีปนาวุธ Nike ระบบคอมพิวเตอร์ที่ผมบริหาร และหลายแง่มุมอื่นๆ ของงานที่ Bell Telephone Laboratories สอนผมข้อเท็จจริงของ systems engineering—ไม่ใช่แบบทฤษฎี แต่เป็นบทเรียนแข็งๆ ที่แสดงให้เห็นทุกวันโดยคนโง่ๆ ที่ไม่เข้าใจทั้งระบบเป็นภาพรวม แต่เข้าใจแต่ส่วนประกอบ ผมเคยสังเกตว่าผมไม่ได้เข้าใจระบบทันทีเมื่อผมบริหารคอมพิวเตอร์ แต่ผมก็ค่อยๆ ตระหนักว่าคอมพิวเตอร์เป็นเพียงส่วนหนึ่งขององค์กรวิจัยและพัฒนา พวกมันสำคัญแน่นอน แต่สิ่งที่สำคัญในระยะยาวคืองานที่มีคุณค่าต่อระบบ และว่าคอมพิวเตอร์ช่วยองค์กรและสังคมให้บรรลุเป้าหมายได้ดีแค่ไหน ความสะดวกสบายของทีมผู้ปฏิบัติงานคอมพิวเตอร์ไม่สำคัญ
ประเด็นอีกอย่างที่ชัดเจนในซอฟต์แวร์สำหรับคอมพิวเตอร์แต่ก็คงใช้กับฮาร์ดแวร์ด้วยคือ สิ่งต่างๆ เปลี่ยนเร็วมาก จนส่วนหนึ่งของปัญหาการออกแบบระบบคือระบบจะถูกอัปเกรดอย่างต่อเนื่องในวิธีที่คุณยังไม่รู้รายละเอียด! ความยืดหยุ่นต้องเป็นส่วนหนึ่งของการออกแบบสมัยใหม่ทั้งของสิ่งของและกระบวนการ ความยืดหยุ่นที่ฝังอยู่ในการออกแบบไม่เพียงช่วยให้คุณจัดการการเปลี่ยนแปลงหลังติดตั้งได้ดีขึ้น แต่ยังช่วยงานของคุณเองเมื่อมีการเปลี่ยนแปลงเล็กๆ ที่เกิดขึ้นในขั้นตอนสุดท้ายของการออกแบบและในการติดตั้งภาคสนาม ผมไม่รู้ว่าการเปลี่ยนแปลงภาคสนามจะมากมายขนาดนี้จนกระทั่งการทดสอบภาคสนาม Nike ที่ Kwajalein Island ในช่วงแรก เรากำลังติดตั้งและยังมีการเปลี่ยนแปลงภาคสนามออกไปยังพวกเขาอย่างต่อเนื่อง!
ดังนั้นกฎข้อสองคือ:
ส่วนหนึ่งของการออกแบบ systems engineering คือการเตรียมความพร้อมสำหรับการเปลี่ยนแปลง เพื่อให้สามารถทำการเปลี่ยนแปลงได้อย่างเรียบร้อยและไม่ทำให้ส่วนอื่นเสื่อมลง
กลับมาที่การศึกษา เป้าหมายจริงของเราคือไม่ใช่เตรียมคุณสำหรับอดีตหรือแม้แต่วงตอนนี้ แต่เพื่อเตรียมคุณสำหรับอนาคต นี่คือเหตุผลที่ผมเน้นความสำคัญของพื้นฐานในสาขาต่างๆ และตั้งใจละเลยรายละเอียดปัจจุบันซึ่งอาจมีอายุสั้น ผมกล่าวก่อนหน้านี้ว่าอายุครึ่งชีวิตของรายละเอียดด้านวิศวกรรมคือประมาณ 15 ปี—ครึ่งหนึ่งของรายละเอียดที่คุณเรียนตอนนี้อาจไร้ประโยชน์ในอีก 15 ปี
กฎข้อสามคือ:
ยิ่งคุณตรงตามข้อกำหนดมากเท่าไร ประสิทธิภาพจะยิ่งแย่เมื่อต้องรับภาระเกิน
ความจริงของเรื่องนี้ชัดเจนเมื่อสร้างสะพานให้รับน้ำหนักหนึ่ง ๆ การออกแบบที่เรียบร้อยเพื่อตรงตามน้ำหนักที่กำหนดจะพังเร็วขึ้นเมื่อโหลดเกิน การเห็นแบบนี้ยังพบในศูนย์สื่อสารโทรศัพท์ เมื่อออกแบบระบบให้รองรับภาระสูงสุดแล้ว เมื่อมีการล้นเพียงเล็กน้อย ประสิทธิภาพก็จะลดทันที ดังนั้นการออกแบบที่ดีมักรวมการเสื่อมประสิทธิภาพอย่างเรียบร้อยเมื่อเกินข้อกำหนด
ในการเตรียมเขียนบทนี้ ผมอ่านบทความชุดหนึ่งอีกครั้งคือ One Man’s Systems Engineering โดย H.R. Westerman (1975) ของ Bell Telephone Laboratories พวกมันเป็นการอภิปรายเชิงปรัชญาอย่างลึกซึ้งที่ผมรู้จักเกี่ยวกับ “อะไร ทำไม และอย่างไร” ของ systems engineering แม้ว่าผมอาจมีความเห็นต่างเล็กน้อยในบางจุด แต่โดยพื้นฐานผมเห็นด้วยกับเขา ผมคงสรุปสั้นๆ เกี่ยวกับสิ่งที่เขาพูดในสิบบทความโดยมีชื่อว่า:
สรุป: The truth of this is obvious when building a bridge to carry a certain load; the slicker the design to meet the prescribed load, the sooner the collapse of the bridge when the load is exceeded. One sees this also in a telephone central office; when you design the system to carry the maximum load, then with a slight overload of traffic performance degrades immediately. Hence good design generally includes the graceful decay of performance when the specifications are exceeded.
สรุป: In preparation for writing this chapter I reread once more a set of essays, One Man’s Systems Engineering by H.R. Westerman (1975), then of Bell Telephone Laboratories. They are the only deeply philosophical discussion I know of the “what, how, and why” of systems engineering. While I will make small differences at various points from what he says, I am in fundamental agreement with him. I can only summarize, all too briefly, what he says in ten essays whose titles are:
เขาเชื่อในทีมที่บุกปัญหาสำหรับ systems engineering มากกว่าการแก้ปัญหาโดยบุคคลเดียว ในขณะที่ผมจากประสบการณ์จำกัดในงานคอมพิวติ้งซึ่งไม่มีใครอยู่ใกล้ให้ปรึกษา ผมต้องทำงานคนเดียว แน่นอนว่างานของเขายากกว่าของผม
เขาเชื่อว่าผู้เชี่ยวชาญที่มารวมกันเป็นทีมคือพื้นฐานของ systems engineering และระหว่างงานพวกเขาต้องกลับไปที่ความเชี่ยวชาญของตนเพื่อรักษาทักษะ การใช้กลุ่มบ่อยๆ เพื่อดับไฟเป็นอันตรายในระยะยาว เพราะบุคคลจะไม่รักษาทักษะเฉพาะด้านให้คมชัด
เราสองคนเห็นตรงกันว่างาน systems engineering ไม่เคยจบ หนึ่งเหตุผลคือการมีอยู่ของทางแก้เปลี่ยนสภาพแวดล้อมและสร้างปัญหาใหม่ให้ต้องพบ เช่น ขณะที่ผมบริหารศูนย์คอมพิวเตอร์ในยุคแรก ผมมาถึงความเชื่อว่าปัญหาเล็กๆ ค่อนข้างสำคัญกว่าปัญหาใหญ่ บริการที่สม่ำเสมอและเชื่อถือได้ เป็นสิ่งที่พึงประสงค์ ดังนั้นผมจึงกำหนดช่วงเวลาในเช้าและบ่ายที่หนึ่งชั่วโมงซึ่งอนุญาตให้มีปัญหาไม่เกินสามนาที (ส่วนใหญ่เป็นการทดสอบโปรแกรม) และถ้าคุณเกินห้านาที คุณจะถูกโดนถอดออกจากเครื่อง คนที่มีปัญหาสิบนาทีต่างก็แบ่งเป็นสามชิ้นเล็กๆ โดยมีคนต่างกันสำหรับแต่ละชิ้นและรันภายใต้กฎ—ซึ่งเพิ่มภาระให้กับช่อง input/output นโยบายของผมเองกลับเปลี่ยนการตอบสนองของระบบ กลยุทธ์ที่เหมาะกับบุคคลชัดเจนว่าไม่สอดคล้องกับกลยุทธ์ที่เหมาะสมสำหรับทั้งห้องปฏิบัติการ และเป็นหน้าที่ของ systems engineer ที่จะขัดขวางการปรับแต่งท้องถิ่นของบุคคลในระบบและมุ่งสู่การปรับแต่งระดับรวมของระบบ
เหตุผลที่สองที่การออกแบบของ systems engineer ไม่เคยเสร็จสมบูรณ์คือ ทางแก้ที่เสนอสำหรับปัญหาเริ่มแรกมักนำมาซึ่งทั้งความเข้าใจที่ลึกขึ้นและความไม่พอใจในหมู่วิศวกรเอง ยิ่งกว่านั้น ในขณะที่ขั้นตอนการออกแบบไหลจากข้อเสนอไปสู่การประเมินและย้อนกลับไปซ้ำๆ ก็จะมาถึงจุดหนึ่งที่กระบวนการปรับนิยามต้องหยุดและต้องเผชิญกับปัญหาในทางปฏิบัติ—ซึ่งอาจทำให้ได้ทางแก้ที่ระยะยาวถือว่าเป็นทางแก้ย่อยที่ไม่สมบูรณ์
Westerman เชื่ออย่างที่ผมเห็นว่า แม้ลูกค้าจะพอรู้ถึงอาการบางอย่าง แต่เขาอาจไม่เข้าใจสาเหตุที่แท้จริง และเป็นเรื่องโง่ที่จะพยายามรักษาเพียงอาการเท่านั้น ดังนั้นในขณะที่ systems engineers ต้องฟังลูกค้า พวกเขาควรพยายามดึงความเข้าใจเชิงลึกเกี่ยวกับปรากฏการณ์จากลูกค้า ส่วนหนึ่งของงานของ systems engineer คือการกำหนดว่าในความหมายที่ลึกซึ้งแล้ว ปัญหาคืออะไร และเปลี่ยนจากการจัดการกับอาการไปสู่การหาสาเหตุ
เช่นเดียวกันที่ไม่มีระบบตายตัวให้หาทางแก้ และขอบเขตของปัญหามักยืดหยุ่นและขยายออกไปทุกครั้งที่มีการแก้ไข ดังนั้นบ่อยครั้งจึงไม่มีทางแก้สุดท้าย แต่ทุกวัฏจักรของข้อมูลเข้าและการแก้ไขก็คุ้มค่าที่จะทำ ทางแก้ซึ่งไม่เตรียมความพร้อมสำหรับรอบถัดไปด้วยความเข้าใจที่เพิ่มขึ้นแทบจะไม่ใช่ทางแก้เลย
ใจกลางของ systems engineering น่าจะเป็น การยอมรับ ว่าไม่มีปัญหาตายตัวหรือทางแก้สุดท้าย แต่อวิวัฒนาการคือสภาพธรรมชาติของสิ่งต่างๆ นี่แน่นอนไม่ใช่สิ่งที่คุณเรียนในโรงเรียน ซึ่งให้ปัญหาที่ชัดเจนและทางแก้ที่ชัดเจน
แล้วโรงเรียนจะปรับตัวอย่างไรเพื่อสอน systems engineering ซึ่งยิ่งมีความสำคัญขึ้นเพราะสังคมมีความซับซ้อนมากขึ้น? แนวคิดการสอนแบบห้องปฏิบัติการดูน่าสนใจจนกว่าคุณจะพิจารณาผลที่ตามมา systems engineering ที่กล่าวมาขึ้นอยู่กับการสอนเทคนิคที่แน่นอนเพื่อแก้ปัญหาที่แน่นอนตามแบบฉบับโรงเรียน องค์ประกอบใหม่คือ การกำหนด ปัญหาให้ชัดจากพื้นหลังแห่งความไม่แน่นอนซึ่งเป็นพื้นฐานของสังคมเรา เราไม่สามารถละทิ้งการฝึกแบบดั้งเดิมได้ และโรงเรียนไม่มีเวลาและทรัพยากร ยกเว้นในกรณีพิเศษ เพื่อรับภาระหัวข้อใหม่ systems engineering ผมคิดว่าที่ทำได้ดีที่สุดคือการอ้างอิงอย่างสม่ำเสมอว่าโซลูชันในห้องเรียนที่เราสอนต่างจากความเป็นจริงของ systems engineering อย่างไร
Westerman เชื่อว่า ศิลปะของ systems engineering ต้องเรียนรู้ในทีมที่ประกอบด้วยผู้มีประสบการณ์และคนใหม่ เขาเห็นด้วยว่าผู้มีประสบการณ์ต้องค่อยๆ ถูกดึงออกและคนใหม่ต้องถูกนำเข้ามาในทีม ผมไม่มีคำตอบสำหรับการสอนประสบการณ์แบบ “lone wolf” ของผม นอกจากสิ่งที่ผมทำมาแล้ว คือเล่าเรื่องที่เกิดกับผมในสถานการณ์ต่างๆ โดยปกติสถานการณ์จริงจะซับซ้อนมากจนต้องใช้เวลานานมากในการถ่ายทอดนโยบายภายนอก นิสัยองค์กร ลักษณะของบุคลากรที่จะมาดำเนินระบบ สภาพการปฏิบัติในสนาม ประเพณี ฯลฯ ซึ่งล้อมรอบและในระดับมากก็ควบคุมทางแก้ที่เสนอให้กับโจทย์ systems ทางแก้มักเป็นความประนีประนอมระหว่างเป้าหมายที่ขัดแย้งกัน และนักศึกษาแทบไม่เห็นความสำคัญของส่วนที่จับต้องไม่ได้ของขอบเขตที่กำหนดรูปร่างของคำตอบ ดังนั้นปัญหา systems engineering จริงๆ แทบเป็นไปไม่ได้ที่จะนำเสนอในรายละเอียดที่สมจริง เหมือนต้องใช้สถานการณ์จำลองและเรื่องเล่าที่ถึงแม้จะตัดรายละเอียดมากแต่ก็ไม่บิดเบือนมากเกินไป
ถ้าคุณย้อนกลับไปดูบทต่างๆ ที่ผ่านมา คุณจะพบเรื่องแบบนี้มากมาย—เรื่องเล่ามักเกี่ยวกับสถานการณ์ systems engineering ที่ถูกทำให้เรียบง่ายมาก ผมคิดว่าผมเป็น systems engineer โดยแท้และเป็นเรื่องหลีกเลี่ยงไม่ได้ที่ผมจะเอนเอียงไปในทิศทางนั้น แต่ขอให้ผมบอกอีกครั้งว่า systems engineering ต้องสร้างบนพื้นฐานที่มั่นคงของการทำเรื่องให้เรียบง่ายทางคลาสสิกสำหรับปัญหาที่ชัดเจนและมีทางแก้ชัดเจน ผมสงสัยว่ามันจะสอนตั้งแต่ต้น (ab initio) ได้หรือไม่
ขอปิดท้ายด้วยข้อสังเกตว่าผมเห็นทางแก้มากมายที่แก้ปัญหาไม่ถูกต้องได้อย่างถูกต้อง ในแง่หนึ่ง systems engineering พยายามแก้ปัญหาที่ถูกต้อง อาจจะผิดไปบ้าง แต่ด้วยความเข้าใจว่าวิธีแก้นั้นเป็นเพียงชั่วคราว และต่อมาระหว่างรอบการออกแบบถัดไป ข้อผิดพลาดเหล่านี้สามารถถูกจับได้ โดยมีเงื่อนไขว่า มีการได้มาซึ่งความเข้าใจ ผมพูดไปแล้วแต่ขอพูดอีกครั้ง: ทางแก้ที่ไม่ให้ความเข้าใจเพิ่มขึ้นกว่าตอนเริ่มต้นเป็นทางแก้ที่ไม่ดีจริงๆ แต่ก็อาจเป็นสิ่งที่ทำได้ภายใต้ข้อจำกัดด้านเวลา ความเข้าใจระยะยาวเกี่ยวกับธรรมชาติของปัญหาต้องเป็นเป้าหมายของ systems engineer ขณะที่ลูกค้าต้องการการบรรเทาอาการของปัญหาในปัจจุบันทันที อีกครั้ง นี่คือความขัดแย้งที่นำไปสู่แนวทาง meta-systems engineering!
ตัวอย่างของการเพิ่มพูนความเข้าใจของเราต่อระบบและปัญหาของมัน ให้พิจารณาโครงการนำวิถีนำขีปนาวุธ Nike: ในตอนแรกตั้งใจสร้างขีปนาวุธที่จะยิงตกเป้าหมายเดี่ยว เมื่อสำเร็จ เราก็เริ่มคิดถึงแบตเตอรี่ Nike หลายลูกและวิธีประสานขีปนาวุธแต่ละลูกเมื่อถูกโจมตีโดยฝูงเครื่องบินศัตรู ต่อมามีวันที่เราเริ่มคิดว่าจะปกป้องเป้าหมายใด เมืองใด และเมืองใดไม่ควรปกป้อง เราเริ่มตระหนักว่าคำตอบคือทุกเป้าหมายควรมีความแพงเท่ากันสำหรับศัตรู—ไม่ควรมีเป้าหมายที่ถูกป้องกันน้อยหรือมากเกินไป แต่ละเป้าควรป้องกันตามสัดส่วนของความเสียหายที่ศัตรูสามารถก่อได้ ดังนั้นเราเห็นว่า Nike เป็นเพียงอุปกรณ์ทำให้ศัตรูจ่ายค่าความเสียหายที่เขาสามารถก่อ โดยไม่มีเป้าถูกป้องกันแบบ "ถูก" ซึ่งมุมมองนี้ต่างจากมุมมองเริ่มแรกมาก มันแสดงว่าทุกทางแก้ควรนำมาซึ่งความเข้าใจที่ลึกขึ้น: อาการที่ลูกค้าระบุจะไม่คงทนเมื่อคุณเริ่มประสบความสำเร็จ เป้าหมายจะเปลี่ยนไปตามที่คุณและลูกค้าเข้าใจลึกขึ้น
Systems engineering เป็นงานที่น่าหลงใหลจริงๆ แต่เป็นงานที่ปฏิบัติยาก มีความต้องการ systems engineers ที่แท้จริงสูง และอาจมีความจำเป็นมากกว่าที่จะกำจัดผู้ที่พูดเก่งแต่เล่นเกมไม่ได้
สรุป: As an example of the deepening of our understanding of a system and its problems, consider the Nike guided missile project. At first it was to build a missile which would shoot down a single target. This accomplished, we began to think of a battery of Nike missiles and how to coordinate the individual missiles when under attack by a fleet of enemy airplanes. Then came the day when we began to think about what targets to defend, which cities to defend, and which not to. We began to realize the answer is all targets should be equally expensive to the enemy—there should be no under-defended or over-defended target, each should be defended in proportion to the damage that could be done by the enemy. Thus we began to see the Nike missile is merely a device to make the enemy pay a price for the damage he can inflict, with no “cheap” targets available. How different this view is from the one with which we began! It illustrates the point that each solution should bring further understanding of the problem: the first symptoms they tell you will not last long once you begin to succeed; the goal will be constantly changing as your and the customer’s understanding deepen.
สรุป: Systems engineering is indeed a fascinating profession, but one which is hard to practice. There is a great need for real systems engineers, as well as perhaps a greater need to get rid of those who merely talk a good story but cannot play the game effectively.