馮燕

近年來，中國的汽車市場迎來了爆發(fā)式的增長，從2010年開始，中國一躍成為世界規(guī)模第一的汽車生產(chǎn)國，成為全球最具活力的汽車市場之一，全國各省市先后出臺了促進汽車產(chǎn)業(yè)發(fā)展的規(guī)劃，各大汽車廠商也紛紛跑馬圈地，產(chǎn)能成倍地增長。這意味著汽車廠商在迎來千載難逢的市場機遇的同時，也必將面臨著激烈的市場競爭。

本文將通過對北京汽車股份有限公司（以下簡稱“北京汽車”）零部件采購現(xiàn)狀的分析，運用項目管理的方法來規(guī)劃和實施采購信息化系統(tǒng)建設，同時和大家分享項目實施過程中在范圍管理、溝通管理和質(zhì)量管理方面的一些經(jīng)驗。

一、北京汽車零部件采購現(xiàn)狀

2010年9月，北京汽車正式成立，雖然有不少有經(jīng)驗、背景的人才加入，但是對北汽自主品牌來說，從研發(fā)、采購到生產(chǎn)的全過程還是像個蹣跚學步的小孩，一點點在摸索中成長。就零部件采購來說，其存在的主要問題是：整車廠以自身利益為中心， 不顧零部件企業(yè)的實際情況和利益， 用零部件企業(yè)的大量庫存來換取自身的零庫存， 并把價格戰(zhàn)的壓力推向零部件企業(yè)， 導致汽車行業(yè)整體供應鏈競爭力減弱；信息溝通的手段和工具落后，主要還是采用傳統(tǒng)方式（ 電話、傳真、信件、E - mail）與供應商進行信息交流， 使信息不能及時傳達， 導致采購效率低下， 企業(yè)對市場的反應速度遲滯， 造成生產(chǎn)與市場的脫節(jié)， 而供應商為了適應由于信息不暢造成的需求變化， 只得加大庫存量， 導致流動資金占用過多；零部件定點和開發(fā)認可進度風險管控困難，成本對標與統(tǒng)計完全靠手工臺賬處理，人員流失導致數(shù)據(jù)信息流失，這種狀態(tài)已經(jīng)嚴重制約了采購業(yè)務的開展，尤其是在整車行業(yè)競爭如此激烈的大環(huán)境下，要求規(guī)范采購業(yè)務流程、提高工作效率、與供應商協(xié)同合作、共同發(fā)展的呼聲越來越高，采購信息化管理也就勢在必行。

二、北京汽車采購信息化系統(tǒng)分階段實施計劃

2011年下半年，在北京汽車各方領導的大力支持下，采購中心協(xié)同信息技術(shù)部開始規(guī)劃零部件采購信息化系統(tǒng)，即SRM（Supplier Relationship Management，供應商關(guān)系管理）系統(tǒng)，這個系統(tǒng)是一種不斷優(yōu)化供應商選擇，縮短采購周期，貫徹集中采購，并實現(xiàn)與供應商建立和維持長久、緊密伙伴關(guān)系的管理思想和軟件技術(shù)解決方案。筆者作為該項目的項目經(jīng)理有幸參與了整個規(guī)劃和實施過程。根據(jù)采購實際業(yè)務開展的緊迫程度，將系統(tǒng)規(guī)劃實施分成三個階段進行，具體安排見下表。

三、北京汽車采購信息化系實施過程的管理模式

1.項目組織類型選擇

由于采購SRM系統(tǒng)開發(fā)與實施涉及多個部門，如生產(chǎn)部門、零部件采購部門、供應商管理部門、財務部門、信息技術(shù)部、軟件開發(fā)商等，根據(jù)項目需要每個部門需要安排一名關(guān)鍵用戶，對參與項目的關(guān)鍵用戶的要求是對部門業(yè)務熟悉且表達能力強，同時需求調(diào)研階段和測試階段需要全程參與，其余時間還是要參與到部門事務中去，所以項目的組織類型選擇矩陣式管理。矩陣式管理較其他組織結(jié)構(gòu)相比，至少有三大優(yōu)點：一是提高工作效率，由于采用了靈活的組織結(jié)構(gòu)，在資源上進行了共享，當項目出現(xiàn)的時候，可以馬上調(diào)集與之相匹配的資源，組建跨功能部門的項目團隊，提高了團隊執(zhí)行力，減少了溝通環(huán)節(jié)，加快了信息的共享，提高了反應速度，矩陣式管理使各個部門的管理聚焦到公司的業(yè)務發(fā)展上，更加有利于公司的戰(zhàn)略實施；二是資源得到共享，在矩陣式的組織結(jié)構(gòu)中，各個部門的資源得到了共享，使資源得到了充分的利用，減少了以前出現(xiàn)的“忙的忙死，閑的閑死”的情況，根據(jù)研究表明，采用矩陣式的管理模式比采用傳統(tǒng)組織結(jié)構(gòu)的管理模式要減少20%的資源；三是更加有利于人才的發(fā)展，采用矩陣式管理模式并不會影響到人才的晉升通道，而且采用跨部門的協(xié)作模式，有利于提高員工的綜合能力的培養(yǎng)。矩陣式管理更加有利于人員的團隊合作精神，避免了以前的部門本位主義。

2.項目的范圍管理

項目范圍是指為了達到項目目標，項目所規(guī)定要完成的工作及過程。利益相關(guān)方必須在產(chǎn)品方面達成共識，也要在如何完成這一項目達成一致的意見。項目范圍管理是指對項目包括什么與不包括什么定義與控制的過程。這個過程用于確保項目團隊和利益相關(guān)者對作為項目結(jié)果的項目產(chǎn)品以及生產(chǎn)這些產(chǎn)品所用到的過程有一個共同的理解，簡單地說，項目范圍管理就是為項目劃定一個界限，劃定哪些方面是屬于項目應該做的，哪些是不應該包括在項目之內(nèi)的，定義項目的工作邊界，確定項目的目標和主要的項目可交付成果。

針對SRM項目實施來說，需求調(diào)研階段生成的需求文檔就是對系統(tǒng)開發(fā)范圍的界定，這個也是整個項目實施中的重點和難點，一般會占整個開發(fā)周期三分之一的時間?！澳サ恫徽`砍柴工”，前期需求越明確，后續(xù)開發(fā)返工才會越少，進度才越有保障。否則有可能開發(fā)出來的產(chǎn)品和業(yè)務部門想要的內(nèi)容南轅北轍，項目只能以延時或是失敗告終。需求調(diào)研階段，首先根據(jù)立項報告中的功能模塊定義，規(guī)定好每個模塊的調(diào)研時間，也就是確認需求調(diào)研計劃和參與人員，當然時間是很緊湊的了。然后，我們組織關(guān)鍵用戶和軟件公司開發(fā)顧問一起進行頭腦風暴，每個人根據(jù)自己業(yè)務的實際需要，提出需要哪些功能，業(yè)務流程應該是什么樣的，頁面該如何展示，審批流程應該是什么樣的等等，開發(fā)顧問會詳細記錄這個需求內(nèi)容，同時對討論未決事項確定責任人，需要找相關(guān)領導確認明確需求，并生成會議紀要下發(fā)再次征詢意見。討論會后，需要關(guān)鍵用戶將模塊的業(yè)務流程進行梳理，生成模塊的流程圖。每個模塊大概都需要三輪需求討論才能定第一稿需求文檔。由于關(guān)鍵用戶一般都是業(yè)務骨干，但不是部門經(jīng)理，沒有決定權(quán)。第一稿確定后，需要集中各部門領導進行宣講和征詢意見，根據(jù)領導的意見再次修改后審批完成才能最終定稿。需求文檔必須明確標記每個模塊需要哪些頁面、頁面功能和字段有哪些、頁面功能之間的關(guān)系、權(quán)限的設定、審批流等詳細信息。同時為了以防萬一，擔心開發(fā)人員理解有誤，需要軟件開發(fā)商根據(jù)需求文檔提供系統(tǒng)界面原型，作為需求調(diào)研階段另一個交付物，界面原型同樣需要關(guān)鍵用戶和相關(guān)領導審批通過才能生效，這也是需求調(diào)研階段的雙保險，根據(jù)以往的經(jīng)驗，這樣做后續(xù)開發(fā)過程中的分歧會比較少。

當然，再完善的需求也很難避免由于各種原因而出現(xiàn)需求變更或新增需求（范圍變更）的問題。針對需求變化，首先需要提出部門提交變更申請單，項目組內(nèi)部進行綜合評估，首先判斷這個需求是否真的有必要體現(xiàn)，如果需要，就要看需求變更對其他功能的影響，影響有多大；如果該變更不開發(fā)將影響其他業(yè)務流程，那一定要在本期上線前開發(fā)完成，否則系統(tǒng)無法使用。這種情況就需要調(diào)整開發(fā)計劃，形成新的項目計劃基線。如果該變更是單獨功能，不影響其他功能的使用，看開發(fā)進度是否允許，時間充?？梢陨暇€前開發(fā)；否則協(xié)商后可以系統(tǒng)上線后開發(fā)，但規(guī)定好具體完成時間。如果經(jīng)項目組評估后覺得功能根本沒必要體現(xiàn)，需求變更不予實施。變更申請單需要層級審批后，由開發(fā)經(jīng)理評估費用和時間進度，按計劃執(zhí)行。變更申請單由信息技術(shù)部存檔，作為項目收尾時結(jié)算的依據(jù)。

3.項目的溝通模式

項目溝通主要是項目團隊與其他組織、項目團隊成員之間的信息傳遞和理解。項目溝通貫穿于項目的整個生命周期，在確認系統(tǒng)需求階段需要溝通；在項目計劃階段制定各類計劃時需要溝通；系統(tǒng)開發(fā)和實施階段需要溝通；在系統(tǒng)測試階段需要溝通，以及上線運維階段都需要溝通；可見溝通在整個項目實施過程中的重要地位，有效的溝通對項目的成功具有重要的意義。如果溝通不暢，相關(guān)人員不能理解項目經(jīng)理的意圖，無法做到上傳下達，最終會導致項目混亂甚至失敗。另一方面，項目團隊內(nèi)部及其與外部環(huán)境之間的信息溝通可以使項目組及時準確地獲取項目的進展情況，對項目進行合理的組織和控制，因為只有以準確、完整、及時的信息為依據(jù)，項目組才能做出正確的決策和合理的計劃。

針對SRM項目來說，采用的是輪式溝通渠道模式，就是項目經(jīng)理作為信息中心分別與項目中不同類型角色發(fā)生聯(lián)系，集中匯集和傳遞來自各個部門的信息，但是不同角色之間彼此之間不發(fā)生聯(lián)系，只分別掌握本部門的情況，接受主管人員的指令并反饋信息。溝通的方式主要以書面溝通的形式，會議上溝通討論的以會議紀要為準，個別溝通的內(nèi)容以郵件為準，或是根據(jù)項目要求提交各類報告，這些信息可以長期保存且信息描述周密、邏輯性強，不容易產(chǎn)生誤解和糾紛。但是缺點是耗費的時間比口頭溝通要多，同時無法保證接收者是否能夠正確理解，綜合兩者的優(yōu)缺點，我們最終采用的溝通方式是以書面溝通為主，口頭和書面相結(jié)合的方式，每次口頭溝通后會落實到文字上雙方認可再實施，保證溝通的有效性。

4.項目的質(zhì)量管理

項目質(zhì)量管理是為滿足項目利益相關(guān)者的需要而開展的項目管理活動。針對SRM項目的質(zhì)量管理就是軟件功能測試，包括單元測試和集成測試。由于我們此次合作的軟件開發(fā)商沒有專業(yè)的測試團隊，只是開發(fā)人員交換測試，一方面由于時間進度緊而測試不充分，另一方面對別人開發(fā)的模塊需求不清晰測不出業(yè)務流程的正確與否。所以到單元測試和集成階段，關(guān)鍵用戶就要參與進來，每個關(guān)鍵用戶測試自己所熟悉的領域，除了對頁面字段功能進行驗收外，還要對功能之間的業(yè)務邏輯進行驗證，這樣開發(fā)與測試并行進行，有利于保證進度。但是從另一方面來看，我們收到的最初的交付物錯誤百出，通過問題清單的形式發(fā)給開發(fā)經(jīng)理進行修改和再次發(fā)布驗證。雖然我們驗證的比較充分，但是這樣項目組面對的工作量就會成倍的增加。建議以后最好選有專業(yè)測試團隊的軟件開發(fā)商，讓其分擔項目組的測試工作量。

四、小結(jié)

最終采購信息化系統(tǒng)SRM項目分階段都如期完成，每個項目上線后都會進行項目總結(jié)和經(jīng)驗分享，讓項目組成員在業(yè)務能力上能得到很好的提升。有效地運用項目管理的方法和工具對項目成功實施至關(guān)重要，但是也要活學活用。作為一名合格的項目經(jīng)理，是在不斷學習中成長起來的，要善于從每個項目中總結(jié)經(jīng)驗才能不斷進步。

（作者單位：北京汽車股份有限公司）