0 引言
技術狀態管理(CM)是系統工程管理的重要工具,是項目管理、質量管理的重要組成部分。技術狀態管理涵蓋了整個產品全壽命周期,包括市場需求、研發設計、生產制造、交付客戶、服務等,目的是使設計結果與客戶需求保持一致、制造結果與設計需求一致、交付產品與制造結果保持一致。這種一致性是由航空、航天產品研制的復雜性和特殊性決定的。
技術狀態管理通常包含標識、控制、紀實、審核四項活動。四項活動貫穿于整個武器裝備科研生產的全壽命周期。其中技術狀態標識不僅是技術狀態管理的起點,同時也是整個武器裝備壽命周期保持“三個一致”的基礎。
1 技術狀態標識
1.1 技術狀態標識的內涵
技術狀態管理的前提是技術狀態標識。沒有完善的技術狀態標識,就不可能有完善的技術狀態管理。“標識”絕非“標記”,它有一個識別、確認的過程。如果將技術狀態標識僅僅理解為對技術狀態文件的標記,是不全面的。
技術狀態標識起始于武器裝備研制的方案探索階段。客觀上說,該階段武器裝備的功能、物理特性的定性功能比例遠高于定量的指標。在技術狀態標識的過程中,最重要的活動是選擇技術狀態項目和建立技術狀態基線。通過技術狀態標識工作,技術狀態才有了“可見性”。
技術狀態標識需要進行以下活動:
(1)在確定項目分解結構的基礎上選擇技術狀態項;
(2)確定每個技術狀態項所需的技術狀態文檔;
(3)指定技術狀態項及其技術狀態文檔的標識;
(4)發放和保持技術狀態文檔;
(5)建立技術狀態基線。
其中第(3)~(4)項活動是實施層面的內容,一般承(研)制單位都有設計、文檔、圖樣的標識管理制度或辦法,這里不再贅述。而第(1)~(2)項內容是型號技術狀態管理必須自己指定并完成的。從某種意義上說,技術狀態管理項目是事關研制項目成敗的“珍珠”,將散落的珍珠匯成一條線管理,就是技術狀態基線管理。而技術狀態項目的選擇是受技術、管理、風險、資金、進度共同約束的。第(5)是前四項工作完成后,建立技術狀態基線就落實在技術狀態文檔中。顯然,繪制項目分解結構框圖(WBS)是技術狀態標識的首要工作。
1.2 WBS(工作分解結構)
工作分解結構是項目管理通用和惟一的參照系。GJB2116《武器裝備研制項目工作分解結構》標準給出了典型的上三級(“綱要WBS”),而技術狀態項目就是從工作分解結構有關單元中選出來的。“高層次的技術狀態項目應在論證階段或方案階段的初期選定(形成功能技術狀態基線)”、“低層次的技術狀態項目應在工程研制階段初期或其之前選定(形成分配技術狀態基線)”。比如方案階段識別了若干項,形成了系統規范,到工程研制階段合同WBS和擴延的合同WBS階段,WBS的層數由原來的三級可能增加到五級,甚至八級,技術狀態項目的選擇數量肯定有所增加。所以技術狀態項目的選擇是一個動態、遞增、要求變化的過程。
武器裝備系統研制和生產的規劃、實施及控制,都應有一個完整的層次體系作為貫穿整個研制生產過程的總脈絡。圖1是某型飛機首3級綱要WBS單元和4級以下WBS單位代碼的細化示例。
圖1 飛機系統WBS單元代碼層次結構圖示例
在WBS項目分解結構過程中,一些承(研)制單位對單元代碼的標識未按國軍標要求,經常出現通用單元代碼和產品單元代碼混淆不清。按照GJB5427規定,編碼順序是每個層級由2位十進制數字構成并遞增的;常出現的錯誤還有:奇數位編碼、編碼中含字母代號、編碼不能完整標識產品所在的層次等。
1.3 工程項目WBS
綱要WBS形成了在研制和生產各階段中供制定計劃和安排經費的統一框架。在飛機的工程項目的WBS表(見表1)可以看出,“0301”單元研制試驗和評定有10項內容,其中的“030110”單元“調整試飛與驗證試飛”中,又分解了23項不同的試驗。
表1 飛機WBS表
有的承(研)制單位在項目的實際分解過程中,注重產品結構分解,對通用單元部分卻沒有分解細化。其直接導致的后果是通用單元中如試驗、訓練、文件、保障等許多事關武器綜合效能發揮的研制工作因未納入早期的技術狀態項目管理而被忽視,這也將最終影響整個項目的進展和完成質量。
1.4 SOW(工作說明編寫)
目前在我國新研武器系統領域,由于技術跨度大、研制周期短,新成品所占比例已經超過了風險控制范圍,如果還是僅按技術協議書進行驗收把關,不進行中間研制過程的控制,風險是很大的。為了規避風險,以及根據在與外方合作中的體會和感受,在簽定大量的新成品技術經濟合同和技術協議的同時,也都簽定了一份SOW。
編制工作說明來源于工作分解結構。在工作分解結構安排下,工作說明的組成部分能得到合理的安排,并可以追蹤到每一組成部分下擴展的工作項目。
工作說明明確提出工作范圍和工作要求。承制方依據工作說明安排武器裝備項目的研制生產,訂購方按照工作說明檢查承制方履行合同的情況。
工作說明一般要明確輸入和輸出及控制要求。在對產品控制要求逐漸明晰的技術背景下,WBS單元中那些符合作為技術狀態項目控制的單元也就逐漸浮出“水面”,技術狀態的選擇也就是順理成章的事了。
WBS與SOW的聯系如表2所示。
表2 WBS與SOW的聯系
2 技術狀態項目(CI)的選擇
2.1 技術狀態項目一般選擇準則
GJB3206將技術狀態項目定義為:能滿足最終使用功能,并被制定作為單個實體進行技術狀態管理的硬件、軟件或其集合體。一般情況下,可將下述項目選為技術狀態項目:
(1)武器裝備系統的系統、分系統級和跨單位、跨部門研制的項目;
(2)在風險、安全、完成作戰任務等方面具有關鍵性的項目;
(3)采用了新技術、新設計或全新研制的項目;
(4)與其他項目有重要接口的項目和共用分系統;
(5)單獨采購的項目;
(6)使用和維護方面需要考慮的項目。
如汽車或其發動機總成,變速箱部件或其中的齒輪、軸承、殼體以及儀表系統軟件都可作為技術狀態項目。
2.2 技術狀態項目選擇的約束條件
2.2.1 技術、管理約束條件
嚴謹的WBS分解和詳細的工作說明SOW是在研制初期進行技術狀態項目選擇的基礎,也就是其技術和管理的約束條件的外在表現形式。技術狀態項目不只限于工作分解結構中的產品體系中的項目,保障體系的重點項目也應列為技術狀態項目,如“專用保障設備”。
2.2.2 接口約束條件
接口是相互關聯項目之間的共同邊界處存在的,使系統、設備、軟件和數據兼容的功能特性和物理特性,其目的是確保單獨設計和采購的關聯項目能共同工作。當項目發生更改時,接口所涉及的功能特性和物理特性應作為設計更改的約束條件。
在MIL-STD-973《技術狀態管理》中對接口要求提出了“系統及其技術狀態項目的接口要求應作為系統工程過程的一部分進行標識”、“成立接口控制工作組(ICWG),明確成員及主席”。由此看來,部分接口管理,也是技術狀態項目的來源。
2.2.3 軟件約束條件
在MIL-STD-973中,明確不管計算機軟件如何儲存,在工程項目整個壽命期內,計算機軟件將視為CSCI(計算機軟件配置項目)。硬件技術狀態項目的縮寫為HWCI,而CI就是技術狀態項目的簡稱。所以軟件也是技術狀態項目來源之一。
2.2.4 數量、風險的約束條件
選擇技術狀態項目時,應考慮經費和人力的承受能力,技術狀態項目太多,將增加管理控制費用和人力,還會增加不必要的設計約束,增加要求編制的文件總數量,增加超過訂購方需要的正式試驗和技術審查,限制承制方快速解決設計中的問題,拖延研制進度。技術狀態項目太少,又會由于缺乏管理的清晰度而冒失控的風險和使用維護的困難。可見技術狀態項目選擇多少,并沒有固定的規定或模式,應根據所研制的裝備的具體情況考慮。
2.2.5 資金、進度約束條件
一旦成為選定的技術狀態項目,按照技術狀態管理要求,需要:
(1)單獨編制規范;
(2)更改需經正式評審;
(3)分別記錄技術狀態狀況;
(4)逐個進行設計審查和技術狀態審核;
(5)單獨進行合格鑒定試驗;
(6)單獨編制使用手冊和用戶手冊。
以上工作是技術管理標準對技術狀態項目的要求。在實際執行過程中,由于有的型號在研制初期并未確定技術狀態項目,所以不可避免地形成全部的功能和物理參數都是技術狀態控制對象的被動局面;有的型號還按照傳統的A/B/C/D/E類規范控制,或1至4級控制,這些都不符合GJB對技術狀態控制項的目的和要求。
綜上所述,一個復雜系統按照上述準則和要求,少則幾十、多則上百都是可能的。具體的數量和控制應以能實現合同雙方預期為目標。
3 結束語
從GJB3206的發布實施至今已過去了十年,航空產品技術狀態發展水平也已經分出了梯隊。在一些新的主機型號飛機研制過程中,基本上全部實現了技術狀態管理。而在發動機部分,國內企業目前還沒有從技術狀態管理的角度開展產品全壽命周期系統管理(PLM)的實施工作,主要還局限于CAD/PDM。在機載系統部分,技術狀態管理的基礎則更為薄弱。
技術狀態管理基礎薄弱的項目或單位,首先是對技術狀態標識認識不足,對WBS、SOW重視程度不夠;其次在CI的選擇上,對約束條件缺乏全局的掌控。因此,除了向主機廠(所)學習外,推進技術狀態標識的信息化管理也是今后工作的努力方向。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:技術狀態項目選擇難點分析