前言：中文期刊網精心挑選了技術變更流程范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
技術變更流程范文1
關鍵詞：載人航天器；軟件需求；變更控制；改進流程
中圖分類號：TP301文獻標識碼：A文章編號：1672-7800（2013）006-0023-03
作者簡介：李皖玲（1980-），女，碩士，中國空間技術研究院載人航天總體部工程師，研究方向為載人航天器信息系統。
0引言
軟件需求在軟件產品的整個生存期中占有重要位置，是軟件工程項目的依據和出發點，無論是軟件開發還是軟件維護，都是以滿足軟件需求為最終目的[1，2]。
在實際工程研制中，用戶需求變更的現象不可避免。美國Standish Group 公司對8 400個軟件項目的調查和研究指出3種最經常使項目遇到困難的因素，其中，不斷改變的需求和規格說明占所有項目的12%[3]。同時，ESPITI機構根據3 800個調查人的回答，管理（更改）需求是被調查者回答的軟件研制過程中最難解決的兩個最大問題之一[4，5]。以航天某型號的某個子系統為例，共有軟件配置項14個，全生命周期共發生需求變更34次，涉及軟件11個，占到軟件總數的78.6%，發生過4次及4次以上需求變更的軟件有4個，占到軟件總數的28.5%。
如何及時、有效地控制軟件需求變更問題，已成為軟件工程化管理不可回避的課題。如果不能對需求變更進行及時有效的控制管理，很可能對整個軟件項目造成“牽一發而動全身”的影響[6]。
1需求變更原因及管理現狀
1.1需求變更原因
載人航天器軟件工程化的一項重要工作是對變更進行控制，以將變更對工作量、工期和質量的影響降低到最小。根據型號研制工作經驗，造成需求變更的原因可總結為以下方面：
（1）系統復雜導致需求理解不完整、不明確。載人航天器研制是個龐大的系統工程，由13個分系統構成，一個系統級功能及任務需層層分解至某個軟件或某幾個軟件來實現，帶來軟件內部、軟件與軟件之間信息流設計復雜、信息交互頻繁。系統需求的復雜性，帶來了對軟件需求理解的不確定性及不完險。
載人航天器軟件需求分析需經過系統級、分系統級、配置項級三級開展，在需求分析階段，若系統級或分系統級未對軟件需求進行深入論證、分析，軟件研制人員也未重視分系統級及系統級人員的參與，導致需求分析工作各自獨立，沒有設計出良好的軟件結構適應變化，造成后期頻繁的需求變更。
（2）工程周期長導致需求不斷加以完善。載人航天器的軟件研制需經歷初樣、正樣階段，一般研制周期為2～3
年。在初樣階段，建立初步的軟件功能基線后，開發工作即開始啟動。隨著軟件研制工作的深入，分系統會提出新的需求。同時，載人航天器系統與子系統按照同一節點進行開發，即使建立的功能基線是無遺漏的、明確的，但隨著工程深入，其中的某個子系統發生任務變更，由此帶來該子系統軟件或其相關軟件需求發生變化。
（3）軟件需求本身特點。軟件需求作為整個軟件項目的最關鍵的一個輸入，同硬件產品不同，具有模糊性、不確定性、變化性和主觀性等特點，它的自身特點就決定了變化的可能[5]。
1.2需求變更管理存在的問題
載人航天器軟件工程化的需求管理方法經過近10年的運行和實踐，確保了多艘航天器軟件安全、穩定運行，詳細流程見圖1所示。但目前需求變更控制流程仍然存在待改進地方，主要體現在以下方面：
（1）需求變更控制方式單一。載人航天器軟件工程化對需求變更的控制方式單一的主要表現，其一是未區分軟件研制不同階段需求變更的處理流程，對需求變更控制和管理均是按照圖1所示的流程進行，實際上，初樣和正樣階段的需求變更，對計劃和質量的影響是完全不同的；其二是對所有的需求變更一視同仁，未區分關鍵性需求和改進性需求，致使需求變更頻繁發生，導致工作量和資源投入的不理性增加。
（2）變更影響域分析滯后。對于分系統提出的變更，多是從技術的角度出發，經過系統級、分系統兩級論證通過后，以技術要求方式下達。一旦軟件研制單位接收到技術要求，按照軟件工程化要求進行軟件變更及影響域分析時，發現由于此次需求變更對軟件架構和研制進度帶來較大影響，并引入了質量風險，也只能按照影響域分析結果進行變更。
2需求變更管理流程改進
設計一個清晰的、明確的、可控的、有效管理的需求變更工作流程，有利于促進軟件開發過程中的人員分工和合作；有利于對需求變更的處理階段進行實時監控和跟蹤[7]。
需求變更控制改進后流程見圖2所示。
2.1變更申請
軟件需求變更申請可由需求方（分系統級）提出，也可由開發方（軟件研制方）提出。
提出的軟件需求變更由開發方歸入“需求變更池”進行管理，“需求變更池”由需求變更時間、需求變更定義、變更原因、提出變更人等信息組成。
根據軟件研制特點和軟件進展階段，需求方定義需求變更周期，每一個需求變更周期對“需求變更池”的需求進行統一處理。如在初樣尚未進入編碼階段，需求變更周期定義為兩周，若在初樣已完成編碼階段，需求變更周期定義為一個月，在正樣階段，將“需求變更池”的處理周期定義為事件驅動。在每一個需求變更周期內，需求方將與開發方一同，對“需求變更池”內的需求處理一次。
采取“需求變更池”管理的好處是將需求變更流程變為周期性，既能確保所有需求申請都能夠得到及時處理并經歷正規的需求管理流程，又能盡可能地減少對軟件研制過程的干擾。
2.2影響域分析論證
當需求變更周期到達時，需求方和開發方將一同進行變更的影響域分析。
若需求方提出需求更改申請，需與軟件經理共同編制需求更動論證及影響分析報告。需求方從更動的必要性、可行性及變更帶來的影響方面進行論證，即是否必須進行設計變更才能滿足預期的性能指標要求和使用要求，或是對此有明顯改善、提出的變更技術上是否合理，工程上是否可行，變更對產品的可靠性、安全性及接口的影響。開發方根據需求跟蹤矩陣，標識并實施因分配需求的更改而引起的項目計劃、軟件工作產品（包含文檔和代碼）和活動的更改。開發方的影響分析包含軟件功能、性能等技術類分析，還應包含管理類的非技術影響分析。
若開發方提出需求更改申請，開發方單獨編寫需求更動論證及影響分析報告，需重點從軟件配置項角度論述更改帶來的影響。
在該流程中，影響域分析論證由需求方和開發方在申請得到響應的第一時間內共同完成，需求變更影響域分析將更全面、更系統也更具體。同時，通過影響域分析，將需求方變更也納入到了工程化管理，既對需求方更改進行了控制，以減少不必要的軟件變更，又使得開發方能夠及早地參與影響域分析論證，及時應對需求變更。
2.3需求變更評審
軟件配置控制委員會（SCCB）（組成人員中包含需求方、軟件專家）評估需求變更論證及影響分析報告。
2.4需求變更分級管理實施
在進行需求變更評審時，需對需求變更進行定級，針對定級情況實行分級管理，以達到對需求變更的控制和管理。
根據變更影響域分析，可將需求變更定義為4個級別。一級為變更關鍵性需求，如若不變更，意味著整個項目不能正常交付使用，前期工作也會被全部否定；二級變更影響后續關鍵性需求，不影響前面工作內容的交付，但不變更，新的項目內容無法提交或繼續；三級變更為后續重要需求，如果不被滿足會令整體項目工作的價值和開發人員技術價值下降；四級需求是改良性或可選性需求，沒有實施變更并不影響已有功能的使用，代表個人喜好[8，9]。
一二三等級變更，需實施更改；對于四級需求，如果時間和資源條件允許，可實施更改或是后續版本更改。
需求方提出的變更申請，需求方對分配需求進行更改，將變更后的《軟件任務書》批準、受控，下發至軟件研制單位。開發方接收到正式變更要求，類同開發方提出的變更申請，按照軟件工程化管理規定，辦理更改的三單審批流程，實施更改。
2.5通報和跟蹤
SCCB確認需求已進行實際的變更。軟件配置管理工程師通知所有受影響的小組和個人。開發方將因更改而引起的情況通報給受影響的組和個人，對已標識的相關更改進行跟蹤，直到更改結束。
3需求變更管理實踐
上述需求變更管理流程，已被成功應用到某型號某軟件研制過程，該軟件為嵌入式C程序，代碼規模約為12 000～15 000行。在實踐過程中，初樣階段 “需求變更池”處理周期為1個月，正樣階段處理周期定義為“新的需求提出”。至軟件交付時，該軟件共發生軟件需求變更15項，需求方提出需求變更6項，開發方提出需求變更9項，通過需求變更評審，需求變更一級為3項、二級為4項、三級為2項、四級為6項。
通過需求變更管理，該軟件共發生的15項需求變更中，實施了13項，有效地控制了軟件需求變更比率。在未增加開發人員和資源情況下，同軟件開發計劃相比，軟件過程文檔編寫數量減少了16份以上，初步預算節省軟件工程組人員工時80人時以上；同時軟件研制過程可見、受控，軟件研制進展順利，交付進度較計劃時間提前了約60天；軟件在交付使用后，其功能性能滿足用戶需求。
4結語
通過分析軟件項目開發過程中需求變更產生的原因，提出了軟件工程化管理過程中存在的問題，并在此基礎上提出了需求變更管理主流程， 該流程保證變更實施在可控范圍內進行，將影響域分析提至系統級層面，并將需求變更實施分級管理，從而將變更帶來的影響盡可能地降到最小。需求變更管理流程真正將需求方、開發方與需求變化、變更請求和項目管理緊密結合在一起。通過某型號某軟件3年的軟件工程化管理實踐，證實該管理流程使需求變更在項目開發中得到了有序有效管理， 保證了項目的順利完成， 提高了項目的質量。
參考文獻：
[1]韓萬江，姜立新.軟件項目管理案例教程[M].北京：機械工業出版社，2005.
[2]張海藩.軟件工程[M].第1版. 北京：清華大學出版社，2006.
[3]ERACAR Y A， MIECZYSLAW. An architecture for software that adapts to changes in requirement [J] . Journal of System and Software，2000（50）.
[4]STANDISH GROOP. User survey report[R]. European Software Process Improvement Training Initiative， 1995.
[5]秦眾森，李娟.需求變更管理過程機器工具分析與展望[J].計算機工程與設計，2009（11）.
[6]SUZANNE ROBERTSON， JAMES ROBERTSON.掌握需求過程[M].王海鵬，譯.北京：人民郵電出版社，2003.
技術變更流程范文2
ArcGISServer；ArcGIS服務器；GIS；工作流技術；空間數據庫技術
土地變更的過程中，一般涉及到地塊地類屬性的變更、地塊面積的變更、地塊所有權的變更等。采用傳統的土地變更方案，首先需要測量外業部門到野外勘測，再由內業部門依據測量數據繪制變更地圖，最后經過多個行政部門的確認和審批，整個過程步驟繁多，進度緩慢。本次根據土地變更各種環節設計了一個新型的土地變更服務方案，此方案將傳統變更過程中的多個步驟采用一個統一的系統整合到一起，加快變更過程，同時也更好的確保了審批過程中各部門數據的一致。
1.關鍵技術
ArcGISServer系統套件。ArcGISServer是一個企業級GIS應用程序的綜合平臺，提供了創建和配置GIS應用程序和服務的框架，可以滿足客戶端的各種需求也可以處理地理資料。ArcGISServer是一個完整的GIS系統，不僅具有網絡地圖功能，而且具有數據管理、空間分析和可視化服務，它也是創建Web應用程序的一個完整體系。此設計選用ArcGISServer平臺的主要原因有：
ArcGISServer不但有自身特有的各種服務功能，同時還支持額外的OGC服務，包括增強的WMS支持，以及新的WCS和WFS支持。
針對圖像傳輸的新的圖像服務優化。它支持客戶端的采樣壓縮要求，并提供圖像和數據進行分析。這個開放的服務支持SOAPXML、WCS和WMS。此外，用戶可以存儲在地理數據庫或文件系統的柵格數據，還為需要大量基于圖像文件的用戶提供ArcGISServerImage擴展。
ArcGISServer可以對二維的地圖服務進行按需緩存。通過ArcGIS服務管理器，用戶可以定義緩存服務，使之滿足按需緩存，也可以使用ArcCatalog和地理處理工具，以建立興趣區的緩存和修改緩存以包括另外的規模水平。
利用ArcGIS服務器，用戶使用ArcGISServerManager進行安全管理?；诮巧陌踩巹t可以針對應用和服務，允許管理員分配不同水平的特定用戶組的訪問。
ArcGISServer包括一些增強的Web地圖應用。這些改進包括創造一個更精簡的用戶體驗、新地圖、導航和更多的工具，也支持地圖結果的提示和增加打印能力。
ArcGIS服務器包括針對使用JavaScript進行Mashup類型開發的API。它包括面向SOAP和REST服務的Web服務SDK，以及具備Ajax功能WebADFs，以進行高級的網絡和企業應用開發。這些文檔內容已被顯著擴展，特別是針對WebADF、JavaScriptSDK、RESTAPI和SOAPWeb服務的文檔內容。未來還會支持AdobeFlex的ArcGISAPI，這些API可用于創建種類豐富的Web應用程序。
工作流與工作流管理系統。工作流相關概念：工作流是一項借以在分布式辦公環境中定義、執行、監督、協調工作項目流動的技術。工作流管理是一種統攬全局的過程管理工具，利用工作流管理可以對各個業務流程進行控制，并且能夠將不同的業務流程納入到一個總的計劃中加以統一管理。工作流管理系統可以描述不同覆蓋范圍和不同時間跨度的經營過程，根據經營過程以及組成活動的復雜程序，工作流管理系統可以采取多種實施方式，在不同實施方式中，所應用的信息技術、通信技術和支撐系統結構會有很大的差別，工作流管理系統的實際運行環境可以在一個工作組內部，也可以在全單位所有業務部門。
工作流參考模型。工作流參考模型是國際工作流管理聯盟為實現各種工作流管理系統軟件產品之間的有效集成而定義的一個標準模型。它由過程定義工具、工作流引擎、管理監控工具、客戶應用程序、被調用程序這5個標準接口組成。
工作流引擎，是為流程實例提供運行環境并解釋執行流程實例的軟件部件；過程定義工具，是管理流程定義的工具，它可能通過圖形方式把復雜的流程定義顯示出來并加以操作；流程定義工具同工作流執行服務交互；客戶應用程序，是通過請求的方式同工作流執行服務交互的應用，也就是說是客戶端應用調用工作流執行服務；客戶端應用同工作流執行服務交互。被調用程序，是被工作流執行服務調用的應用；調用應用同工作流執行服務交互。為了協作完成一個流程實例的執行，不同的工作流執行服務之間進行交互。管理監控工具，主要指組織機構、角色等數據的維護管理和流程執行情況的監控；管理監控工具同工作流執行服務交互。
2.系統設計與開發
系統總體架構。根據土地變更業務工作的特點，土地變更信息系統主要具有如下幾個特點：管理的動態性；管理的權限性；管理的網絡化；管理多報表化；圖數集成管理。
功能模塊設計。變更項目模塊：在“變更項目”模塊中，分有“最新項目”、“項目申請”、“項目列表”、“項目查詢”四個功能。通過對工作流引擎的調用，在“最新項目”和“項目列表”里面列出了登錄者有權查看的項目。
用戶角色模塊：此方案引入了角色訪問控制的思想，采用了“角色”的概念，目的是為了隔離“用戶”與“權限”。
報表生成模塊：在信息化還沒有得到充分應用前，報表還是上級部門查閱和歷史查詢的主要手段。在變更項目得到批準之后，必須填寫變更相關的報表，系統提供劃定范圍的統計二三級地類的標準報表查詢分析及劃定范圍地類統計專題圖查詢。除了要生成政策文件上規定的報表外，系統應該能采用靈活快速的統計方式，可用結果表現形式來生成自定義報表。
歷史回溯模塊：在這個功能中，用戶可以根據選擇不同歷史時刻的空間數據，瀏覽不同歷史時刻空間數據的變化。所有的ArcSDEGeodatabase均具備Default版本，Default版本為ArcSDEGeodatabase最原始的版本，它是服務器中所有版本的父版本，可以在Default版本或是它的子版本下創建版本，也可以對此版本直接更新。需要注意的是如果要使創建的版本具備歷史回溯功能，在創建版本時應該使數據集具有歷史歸檔功能，這樣才能通過歷史歸檔的記錄回溯到不同的歷史版本。
GIS功能模塊：GIS功能是土地變更服務系統的重要功能。此方案把GIS功能設計成WebGIS的形式，一方面可以有效的把GIS功能與其它Web功能集成在一起，另一方面可以達到“隨時隨地辦公”要求。
此方案在充分分析了土地變更流程的前提下，將GIS、工作流技術、空間數據庫技術相結合。ArcGISServer在本次設計的系統中處于核心地位，設計中將它提供的ArcSDE空間數據庫引擎、時態數據庫進行了實例化。交互方面采用WindowsWorkflowFoundation和組合在一起，提供了一個可測試、可伸縮、可維護的工作流應用方式?；谶@些技術的工作流模型，使得用戶界面的設計和后面工作流代碼的設計分開，同時還使得長耗時的工作流可以使用WF的SQL持久化服務來長期保存。實現了地圖歷史回溯的功能，給土地管理工作帶來了新的方法。
[1]賈勤學，張 瑋，李建林，吳 楠，于麗君.基于遙感技術的耕地面積動態監測研究[J].中國農學通報，2006.07
[2]杜靈通.基于遙感技術的土地利用/覆被變化研究[J].國土資源信息化，2007.02
[3]沈小樂，王 璇，劉 倩.土地利用動態監測技術的研究[J].湖北民族學院學報（自然科學版），2007.03
[4]李懿麟.基于GIS與RS一體化的變更地塊判別方法[J].測繪科學技術學報，2007.z1
技術變更流程范文3
4M變更管理辦法最新版
1、目的
在生產過程中，對影響產品質量的4M要素(人、機、料、法)進行管理和控制，使
這四個因素在保證質量的范圍內安全合理的變動，從而保證產品質量的穩定和提高，符合標準及客戶要求。
2、適用范圍
適用于批量產品生產過程中4M(人、機、料、法)要素的管理。
3、4M定義：
是指批量產品生產過程中，涉及的人(Man)、機(Machine)、料(Material)、法(Method)，
(含環境場所)等給產品質量帶來一定影響的變更。
人(Man)：是指生產過程中作業者因缺勤、調動、離職、代崗或復崗時，由另一個新作業者代替進行作業時，所產生的變更;
機(Machine)：是指生產過程中的設備、模具、工裝、夾具、檢具的新增、修理、代用變更; 料(Material)：是指生產過程中的加工原物料、輔料、包裝物資等變更。
法(Method)：是指生產過程中的工藝流程、工藝參數(設備參數、材料配比等)、檢驗方法、作業方法(制造、整理、包裝、周轉等)變更。
4、職責
4.1變更提出
原則上公司內部變更各部門均可提出申請，并根據變更內容對產品質量的影響程度進行必要研討，經評審后由實施部門負責執行變更;各4M變更實施部門要建立4M變更的臺帳，記錄變更的編號、產品型號和結果等。
4.1.1制造部技術組：負責產品工藝流程、模具、工裝、檢具及方法等變更的實施。
4.1.2制造部生產組：作業人員晉升變更的申請，并根據崗位技能要求進行資格驗證，實施變更;內部變更引起的呆滯物料變更處理的申請，跟蹤等。
4.1.3供應鏈：材料(含構成零部件)變更的申請提出和實施，及供應商的變更受理;
4.1.4工程部：機器，方法、設備變更的申請提出和實施;
4.1.5市場部：負責客戶提出的變更受理，負責收集和內部反饋客戶的評審結果;訂單完成后庫存呆滯料的變更處理的申請，跟蹤等。
4.1.6體系：負責對所有變更事項進行監督及對變更的有效性進行跟蹤確認。匯總4M變更結果，應建立4M變更總臺帳。
4.2 變更評審實施
4.2.1 變更申請通過部門負責人審核后，由申請部門組織相關評審部門，根據變更內容對產品品質的影響程度進行必要的研討;由各評審部門審查確認后，變更責任部門執行變更;或根據變更管理類別(送樣、申請，記錄)由市場項目收集客戶意見后實施; 4.2.3 對相關部門進行變更培訓，記錄保存變更履歷。
注：評審部門包括但不限于技術部門/生產部門/質量部門/采購部門/設備管理部門。
4.2.4 4M變更實施部門對變更過程中可能出現的意外要有應對預案;
4.2.5 4M變更實施部門及相關部門需修訂變更涉及事項(如工程圖紙、SOP、FMEA、控制計劃,SIP，ECN,BOM，QC工程圖，工藝流程圖等);
5 4M變更管理類別：送樣，申請，記錄
5.1 送樣：變更前須試制樣品，并向客戶送樣認可。
5.1.1 變更前，需向部門內部提出變更申請，由實施部門組織評審部門評審，通過后由變更實施部門試制樣品，并向客戶送樣，合格后客戶認可，才能實施變更;
5.1.2 變更申請部門須填寫《(4M)工程更改申請單》并執行4M變更管理流程。 變更實施部門審查后，由變更實施人將通過的《(4M)工程更改申請單》和其它相關評審報告記錄在《(4M)工程更改通知單》中，客戶評價結果由市場部項目收集客戶評價結果反饋給變更實施部門等有關部門，批準生效后，實施工程變更。
5.2 申請：變更須啟動4M變更管理流程進行評審實施。
變更前，需向部門內部提出變更申請，變更申請部門須填寫《(4M)工程更改申請單》并啟動4M變更管理流程。由實施部門組織評審部門評審，經客戶或責任部門確認同意后才能實施變更;
5.3 記錄：此類變更須責任部門記錄并保存。
由責任部門管理記錄相應變更，并保存相關記錄。為了確保變更的履歷(可追蹤性)，供應商應自從該變更品的交貨日算起保管3 年。
6 變更管理內容
6.1 客戶提出的4M變更
客戶提出的4M變更由市場部向公司內部提出申請，按新產品管理流程進行;
6.2 供應商的4M變更
供應商提出的4M變更，由供應商向采購部門提出，向公司內部傳達;
6.3 公司內部的4M變更
6.4 變更點的區分管理
6.5 變更品的首次交貨
6.5.1變更品的首次交貨，需在外包裝箱加貼變更后首批次出貨標簽，并連續3批作出標識。
6.5.2變更品與原來產品在同一批交貨時，需：
1.原來產品與變更品的外包裝分開;
2.在外包裝箱加貼變更后首批次出貨標簽，并連續3批作出標識。
技術變更流程范文4
關鍵詞：電力物資采購合同；管理；流程控制
作者簡介：董付梅（1976-），女，山東臨邑人，山東省臨邑縣供電公司，助理工程師。（山東 德州 251500）
中圖分類號：F272?????文獻標識碼：A?????文章編號：1007-0079（2012）33-0118-02
一、電力物資采購合同管理的意義
實施電力物資采購合同的有效管理能更好地防范電力物資采購風險，能提高物資管理部門的整體管理水平，能加強物資采購合同履行過程的控制，提高合同履約水平，能優化合同管理流程，提高合同管理效率。電力物資采購合同管理堅持依法從嚴管理，嚴格合同簽約履約，深化“集中簽訂、集中結算”的合同管理模式，建立上下聯動、統籌協調的物資現場服務和履約協調機制，通過對物資采購合同的簽約、履約全流程管控實現物資管理的科學化、規范化、標準化、法制化，從而提高了企業的經濟效益，提升了企業的社會形象。
二、電力物資采購合同管理的方法
臨邑縣供電公司電力物資采購合同管理以電子商務平臺和ERP系統為基礎，全過程控制物資合同的簽約、變更、履約和資金結算業務，并采用流程控制方法進行管理。流程控制方法通過流程繪制管理工作的過程，全面描述如何從一個節點流向另一個節點，包括節點具體工作方法、工作工具等的描述以及關鍵節點、創新節點說明。采用流程控制方法，加強物資采購合同全過程管控，以達到標準化、科學化、規范化的要求。
三、物資采購合同標準化管理流程控制
1.流程控制
（1）電力物資采購合同簽約管理流程控制。
1）市公司下發中標結果并確定是否需要簽訂技術協議。一般來說，對于新應用設備材料、技術復雜或項目實施的關鍵設備材料，可根據需要組織項目管理部門、物資需求部門、設計單位等相關部門進行技術協議的簽訂。
2）如果需要則組織簽訂技術協議，由市公司負責組織，縣公司授權項目主管部門負責人與供應商代表簽訂技術協議。
3）縣公司物流服務中心采購員在ERP系統中創建采購訂單。
4）縣公司物流服務中心主任在ERP系統中審批采購訂單。
5）判斷采購訂單是否審批通過。
6）采購訂單審批通過，縣公司物流服務中心主任（公司委托授權人）與供應商代表簽訂物資采購合同。
7）縣公司物流服務中心履約員上報合同簽訂資料。
8）省市公司合同專工匯總合同簽訂資料，提出考評意見并下達。
9）縣公司物流服務中心履約員將合同相關資料歸檔。
（2）電力物資采購合同變更管理流程控制。
1）縣公司項目主管部門根據設計變更通知單提出合同變更申請。根據項目實際要求，需對采購結果進一步補充說明或明確物資合同雙方權利義務的事項，且不造成對采購結果實質性內容進行的更改。
2）縣公司物流服務中心主任審核提報的合同變更申請。審核的依據是物資規格參數不變、單價不變，合同簽訂數量予以增加或減少，增減幅度是否超過招標文件或采購文件約定的15%執行，是否超過50萬元。若合同簽訂數量增減幅度超過招標文件或采購文件約定的15%且超過50萬元，則需重新納入物資計劃采購管理。
3）判斷合同變更申請審核是否通過。
4）縣公司物流服務中心主任審核通過后報縣公司分管領導審批。
5）判斷合同變更申請審核是否通過。
6）縣公司分管領導審批通過后報省市公司物資部專工審批。
7）判斷合同變更申請審批是否能過。
8）省市公司物資部合同專工審批通過后，縣公司物流服務中心履約員根據審批結果確定合同變更方案并通知供應商。
9）縣公司物流服務中心采購員根據合同變更方案在ERP系統內更改采購訂單或增加采購訂單。
10）縣公司物流服務中心主任在ERP系統內審批變更合同或補充合同。
11）判斷變更合同或補充合同審批是否通過。
12）縣公司物流服務中心主任審批合同通過后，縣公司物流服務中心履約員上報合同變更情況。
13）省市公司合同專工匯總合同履約信息，提出并下達考評意見。
14）縣公司物流服務中心履約員將合同變更相關資料歸檔。
（3）電力物資采購合同履約管理流程控制。
1）縣公司物流服務中心履約員在ERP系統內根據采購合同到貨日期制訂物資催交計劃。重要設備材料要及時掌握供應商的生產準備和排產計劃，按照關鍵生產節點，核實生產進度，及時協調解決生產中出現的問題。
2）供應商根據采購合同的到貨日期制訂生產計劃。
3）縣公司物流服務中心履約員對重點物資生產節點履約跟蹤。
4）縣公司物流服務中心建立交貨配送制度。根據合同交貨期和施工進度，履約員及時與物資需求部門確定物資到貨需求，與供應商落實配送安排，編制配送計劃。采用配送單的方式通知供應商發貨和現場服務人員做好接貨準備。
5）供應商按確定的時間和方式交貨。
6）縣公司物流服務中心履約員組織物資需求部門與供應商現場辦理交接手續，并組織項目單位與供應商代表進行物資驗收工作。
7）確定物資驗收是否合格，相關驗收人員在驗收單上簽字確認。
8）物資需求部門與供應商辦理現場交接手續。
9）物流服務中心協調供應商按照合同規定和現場管理的要求安全、優質地完成技術服務、消缺補件、設備安裝調試等工作。
10）縣公司物流服務中心履約員上報合同履約信息。
11）省市公司合同專工匯總合同履約信息，提出并下達考評意見。
12）縣公司物流服務中心履約員將合同履約資料歸檔。
（4）電力物資采購合同資金結算管理流程控制。
1）縣公司物流服務中心履約員根據采購合同提交預付款申請，附物資采購合同、預付款保函和相應的收款收據。
2）縣公司物流服務中心履約員提交到貨驗收款申請，附增值稅發票、項目主管部門簽字確認后的到貨驗收單和相應的收款收據。
3）縣公司物流服務中心履約員提交投運款申請，附運維單位簽字確認后的物資投運單和相應的收款收據。
4）采購物資質保期滿無質量問題的，縣公司物流服務中心履約員提交質保金申請，附項目單位簽字確認后的質保單和相應的收款收據。
5）縣公司物流服務中心核算員匯總履約員提交的預付款申請、到貨款申請、投運款申請、質保金申請，在財務管控系統中編制物流服務中心月度現金流量預算（物資采購支出預算）。
6）縣公司物流服務中心主任在財務管控系統中對物資采購支出預算進行審核。
7）判斷物資采購支出預算審核是否通過。
8）物流服務中心主任審核通過后，縣公司分管領導對物資采購支出預算進行審核。
9）判斷物資采購支出預算審核是否通過。
10）縣公司分管審核通過后，縣公司財務部專工對物資采購支出預算進行審核、匯總。
11）判斷物資采購支出預算審核是否通過。
12）各級審核通過后，財務人員實施預付款處理或應付賬款處理。
2.關鍵節點及創新節點說明
（1）電力物資采購合同簽約管理關鍵節點及創新節點。其中第3）點既是關鍵節點又是創新節點。采購員在ERP系統內創建采購訂單，保存時系統會自動檢查是否超預算。如果超預算，系統會提示并不予通過，此時由采購員聯系采購申請的創建人進入項目變更管理流程調整預算，之后重新維護采購訂單。如果不超預算，采購訂單保存成功。
在ERP系統中采購訂單維護成功后，采購合同、配送單、到貨驗收單、投運單、質保單在系統中以統一的文本格式自動生成，這5種單據可以根據業務進展情況在不同時期打印。為簡化業務流程、提高工作效率，采購員在成功創建采購訂單后將5種單據一次性全部打印，根據具體情況分發給買賣雙方或存檔，尤其是驗收單、投運單、質保單，一次性打印全部由供應商留存，便于在不同時期提交進行資金結算，減少了供應商多次到物流服務中心打印單據的麻煩，為客戶提供了便利。
第6）點既是關鍵節點又是創新節點。物資合同簽訂后，履約員要核實是否需要預付款。如果需要預付款，進入采購付款管理流程。如果不需要，則根據實際情況進入物資收貨流程。
在ERP系統中采購訂單維護成功后，市公司組織供應商與各縣公司集中簽約，嚴格使用國家電網公司物資采購統一合同文本，確保在中標結果后15日內及時完成合同簽訂。嚴格中標結果執行，合同簽訂不得更改中標結果或違背招標、投標文件實質性條款，逐步取消技術協議簽訂，進一步加快合同簽訂速度，大大提高了簽約效率，降低了簽約成本，方便了客戶。
（2）電力物資采購合同變更管理關鍵節點。第9）點，集團公司物資部合同專工審核合同變更申請，若增幅度超過15%或超過50萬，則需轉入物資需求計劃管理流程，新增物資需求計劃；若增幅度不超過15%且不超過50萬，允許合同變更。
（3）電力物資采購合同履約管理關鍵節點及創新節點。其中第3）點是關鍵節點。建立履約管理常態機制，實時監控供應商實際生產狀況、項目進度對物資供應的需求，確保供應商按期供貨、項目單位按期收貨。
第5）點是關鍵節點。供應商是否按照采購合同約定的日期和方式交貨是其履約水平的重要環節，是物資計劃執行準確率的重要因素。
第6）點是關鍵節點。物資的驗收是對物資的數量、外觀、內在質量以及有關技術資料、憑證和物資標志等進行檢查，以驗證物資是否符合合同規定；物資的驗收工作質量的好壞直接關系到整個電網建設和生產的質量。物資到貨驗收合格后必須在合同交貨期滿10日內辦理ERP入庫手續，確保計劃執行準確率達到95%以上。
第12）點是創新節點。在合同履約過程中建立“一單（訂單）一評價”的履約評價機制，及時采集供應商交貨、產品質量和售后服務等信息，對供應商合同履約情況實行卡片式管理，并將結果及時上報。嚴格供應商違約處置，嚴格按照合同約定對供應商違約行為進行當期處理。建立誠信評價機制，對合同簽訂履約情況開展誠信評價，加大對失信行為的懲戒力度，營造誠實守信的良好氛圍。
（4）電力物資采購合同資金結算管理關鍵節點。第1）點物資合同簽訂后，供應商提交預付款申請需出具預付款保函、收款收據和物資合同；若供應商放棄預付款，預付款可與到貨驗收款、投運款一起支付。
縣公司物流服務中心核算員匯總供應商提交的付款申請，在財務管控系統中編制月度現金流量預算。預算編制及資金支付應按照合同相關條款及公司財務相關規定，在付款相應憑據匯集完成后進行。
技術變更流程范文5
【關鍵詞】計算機軟件;eTOM;ITIL;服務保障;生命周期
引言
隨著互聯網技術的迅速發展，通信行業網的業務已經從單一，簡單的通信行業服務逐步過渡到內容增值服務的階段，巨大的市場潛力正在改變整個通信行業市場的運營規則和供應體系，各個通信行業運營商因為競爭和業務發展的需要，都采取了非常積極的營銷措施以提高市場占有率。這些服務和營銷措施的實現都需要計費系統的支持，因此，計費管理平臺面臨巨大的挑戰，需要加強計費系統的可靠性、精確性、高效率、靈活性。
一、計費服務保障生命周期模型設計基礎
1.ITIL對服務支持過程的要求
ITIL（Information Technology Infra-structure Library）是信息技術基礎設施庫。ITIL為企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規范。ITIL的核心模塊是“服務管理”，這個模塊一共包括了10個流程和一項職能，這些流程和職能又被歸結為兩大流程組，即“服務提供”流程組和“服務支持”流程組。其中服務支持流程組歸納了與IT管理相關的一項管理職能及5個運營級流程，即事故管理、問題管理、配置管理、變更管理和管理。
2.eTOM對服務保障和計費的要求
eTOM（enhanced Telecom Operations Map）是增強的電信運營圖，是信息和電信服務行業的業務流程框架，它為服務提供商提供所需要的企業流程。eTOM有三大流程區域：戰略、基礎設施和產品流程、運營）流程、企業管理流程。其中，運營區域是eTOM的核心。包含運營支持與就緒、業務開通、服務保障和計費三個流程組。服務保障流程組負責執行主動的和被動的維護活動，確保提供給客戶的服務是持續可用的、能夠達到SLA（服務等級協議）或QOS（服務質量）所要求的性能水平。計費流程組負責及時準確的賬單，計算客戶使用通信行業業務的應收費用，并完成應收費用的處理與征收。計費模塊與服務保障模塊聯系緊密。這些聯系可以分為計費模塊報告給保障模塊的事件和保障模塊報告給計費模塊的事件。計費模塊將計費系統發生的故障和異常報告給保障模塊處理。保障模塊將服務的執行的相關信息報告給計費模塊，以影響服務費用的計算和收取。服務保障模塊保障了計費模塊的質量。計費模塊根據服務保障模塊的要求進行處理或優化。在通信行業中，服務保障模塊 “監視”著計費系統的質量水平，要求計費系統按照服務保障模塊的要求建立計費系統內各功能模塊，對計費系統中有問題的模塊或不完善的模塊提出要求。計費系統根據此要求不斷完善系統，以達到服務保障的要求。
二、案例分析及研究
1.通信行業計費系統運營維護現狀
本文借鑒某通信行業的計費系統來分析通信行業計費系統生產運營管理和維護支撐現狀，并提出通信行業的計費系統服務保障生命周期模型。此計費系統是集采集、計費、賬務，結算，統計等為一體的大型后臺支撐系統。整個計費體系采取集團管控各省管理和生產的模式。
此計費系統在運營維護方面的五個環節存在以下不足：（1）事故管理方面：人員對故障的判斷和定義不準確，網絡故障定位困難，易受其他系統干擾，在故障處理的專業技術水平方面仍需加強。（2）問題管理方面：問題解決流程不夠完善，系統接口多，難以統一管理，記錄不夠完整。（3）配置管理方面：重視度不足，沒有配置管理方面的文件標準和規范。（4）變更管理方面：文檔不完善，頻繁的變更出現管理疏忽問題。（5）管理方面：單人負責風險高，文檔不完善。本文對五個環節進行了研究，針對計費系統制定出了一套規范的維護流程，計費系統按照研究的流程來規范五個維護環節，將大大提高維護效率。
2.通信行業計費服務保障生命周期模型研究
研究計費系統服務保障生命周期模型，是為了通信行業計費系統能夠按照此模型進行規范和完善。在軟件生命周期的基礎上加強服務保障，以延長和穩定軟件系統。模型圖如下：
圖1 通信行業計費系統服務保障生命周期模型圖
（1）開發
1）軟件需求：軟件的需求管理是整個軟件生命周期的觸發，它直接關系到最終產品的成型。在此階段設計出《軟件需求規格說明書》。
2）軟件開發：在此階段，開發人員根據《軟件需求規格說明書》進行軟件項目的開發。實際執行中，乙方的開發人員一般與甲方的使用人員要進行多溝通，交流，以便更好的了解軟件的需求。
（2）測試
1）軟件測試：軟件測試是軟件生命周期模型中決定軟件質量保證的一個重要的階段。它并不僅僅存在于軟件開發結束以后，他應該伴隨著軟件開發階段，直至軟件的使用。在開發過程中，軟件要進行單元測試、集成測試。在開發完成時，要進行系統測試和驗收測試。驗收測試決定著軟件是否能通過驗收。在軟件使用階段，由于需求的不斷變更和程序漏洞的不斷發現，要進行軟件的回歸測試。
2）軟件試運行：經過軟件測試合格后，軟件進入試運行階段。在此階段，軟件通過多個使用人員的不斷使用，會涌現出很多漏洞或者新的需求。這一階段是發現軟件問題的重要環節，因為開發人員與使用人員的角度不同，共同討論、協商、試用，會幫助軟件更茁壯，更快速的上線。
3）軟件正式使用：經過一個階段的試運行，軟件功能基本穩定，完全滿足所有《軟件需求規格說明書》的要求，滿足全面上線的要求，軟件開始正式使用。
4）軟件驗收：經過軟件各個階段的測試，確認軟件滿足《軟件需求規格說明書》中的要求，并且滿足項目開發前期預定的驗收條件的情況下，軟件進行驗收。
（3）服務保障：根據ITIL中的服務支持流程，要設計計費服務保障流程，必須遵循ITIL中的服務支持流程里的這五個運營級流程，即事故管理、問題管理、配置管理、變更管理和管理。
圖2 故障處理流程圖
圖3 問題報告單處理流程圖
1）計費系統服務保障事故管理：通信行業計費系統在故障管理方面仍需要進一步加強和規范。要制定專門的計費系統故障管理制度。此管控制度應包含以下內容：A.故障時間。B.故障次數。C.故障定義：重大故障、嚴重故障、一般故障。D.故障響應時限，指故障發生至技術人員開始處理故障所經歷的時間。E.故障處理時限，指故障發生至故障處理完成所經歷的時間。F.故障處理的基本原則。G.故障處理要求。H.機房故障處理流程（如圖2所示）。
2）計費系統服務保障問題管理：問題報告單是適用于計費系統內部管理的一種手段，它由產生問題的計費中心將本地網范圍內的問題匯總、分析、過濾、整理后提交該本地網計費中心主任批準，并由其本人或指派專人提交省計費人員，由省中心統一進行管理。問題報告單處理流程如圖3所示。
3）計費系統服務保障配置管理：計費系統在配置管理方面需要制定規范的配置管理流程和管控制度。配置管理的流程模塊圖如下：
圖4 配置管理的流程模塊圖
4）計費系統服務保障變更管理
為規范通信行業計費系統軟件變更管理，提高軟件管理質量，需要下發《計費系統變更管理辦法》。
A.主要目標：主要目標是規范軟件變更管理的人員要求、階段要求，各種形式的軟件變更管理流程，版本管理、文檔管理和進度管理的要求，變更過程中質量保證的要求。
B.制度建立與工位設置：省中心根據軟件分類的不同，應設置以下工位或小組，負責整個軟件變更過程中的管理和實施。軟件變更審批組，軟件變更管理組，軟件變更測試組，文檔管理工位，軟件版本管理工位，軟件質量管理工位。
C.軟件變更管理維護流程
圖5 計費系統服務保障變更管理流程圖
5）計費系統服務保障管理
圖6 計費系統的管理流程圖
計費系統的管理需要有相關管理流程和管控制度，包含以下內容。
A.管理的目標是為了規范計費系統軟件變更的管理。
B.成立專門的軟件項目組。
C.文檔管理要求：軟件需求單，維護文檔，稽核文檔。
D.質量管理及考核。
E.計費系統的管理流程圖（如圖6所示）。
三、總結
通過ITIL對計費系統服務支持過程的要求，可以細化系統的運營維護流程和管控制度;相對于原有流程，工作效率有明顯的提高。通過eTOM對服務保障和計費的支持，結合軟件生命周期的定義，軟件從開發到測試到上線進行規范系統的管理，提高了計費軟件的效率。這兩部分的優化改善完全遵循本文研究的通信行業計費服務保障生命周期模型，直接作用到對企業業務的強有力支撐，從而提高了企業的信息化服務水平，更提高了對客戶的服務水平和客戶的感知，在飛速發展的通信行業里，企業才具有強競爭力。
參考文獻
[1]（英）薩默維爾著.程成，等譯.軟件工程（原書第9版）[M].機械工業出版社，2011.
[2]劉通.ITIL V3服務管理與認證考試詳解（第3版）[M].哈爾濱工業大學出版社，2012.
[3]（荷）博恩著.章斌譯.基于ITIL的IT服務管理基礎篇[M].清華大學出版社，2007.
技術變更流程范文6
服務臺有時也稱幫助臺，即通常人們所指呼叫中心或客戶服務中心，它不是一個服務管理過程，而是一種服務職能。服務臺經常與事件管理緊密結合，用來連接其他的服務管理流程，逐漸被稱為一線服務支持的代名詞。
服務支持
1、配置管理
配置管理是將一個系統中軟件和硬件等配置項資源進行識別和定義，并記錄和報告配置狀態和變更請求以及檢驗配置項的正確性和完整性等活動構成的過程。
2、變更管理
變更管理是要確保在IT服務變動的過程中能夠有標準的方法，以有效的監控這些變動，降低或消除因為變動所造成的問題。它的目的并不是控制和限制變更的發生，而是對業務中斷進行有效管理，確保變更有序進行。
3、管理
管理是指對經測試后導入實際應用的新增或修改后的配置項進行分發和宣傳的管理流程，目的是保障所有的軟件組件的安全性，以確保只有經過完整測試的正確版本得到授權進入正式運行環境。
4、事件管理
事件管理指的是突發事件管理或意外事件管理，處理IT的危機并要從中恢復運轉。即在出現事故的時候，能夠盡可能地恢復服務的正常運作，避免業務中斷，以確保最佳的服務可用性級別。
5、問題管理
問題管理是指負責解決IT服務運營過程中遇到的所有問題的流程。問題管理的主要活動實質上就是分析以被列出問題的事件的根本原因，找出解決方案，把事件的影響最小化，并通過找到已發生事件或潛在事故的根本原因來減少事件的數量或消除事件的再次發生。
服務提供
1、服務級別管理
服務級別管理是一種嚴格的超前方法論和處理程序，是定義、協商、訂約、檢測和評審提供給客戶的服務質量水準的流程。
2、財務管理
財務管理是在提供深入了解IT服務管理流程的基礎上，對IT恢復運作的費用及成本重新分配并進行正確管理的程序，其目標是幫助IT部門在提供服務的同時加強成本效益核算，以合理利用IT資源、提高效益及財務資源使用的有效性。
3、可持續性管理
可持續性管理是指確保發生災難后有足夠的技術、財務與管理資源來確保IT能持續服務的管理流程。
4、容量管理
容量管理是指在成本和業務需求的雙重約束下，通過配置合理的服務能力來確保服務的持續提供和IT資源的正確管理，以發揮最大效能；以合理的成本及時提供有效的IT服務，以滿足組織當前及將來的業務需求。
