按照計畫，下個月中旬，bpr專案將進行啟動大會，下週，乙方入場，在專案啟動之前，專案章程中涉及到專案組織架構、崗位職責、專案目標、專案範圍、里程碑計畫、溝通計畫、人力資源計畫、風險控制計畫、專案制度等等都要明確和落實。
到現在為止，還有專案組人員需要確認和落實。
專案組由業務部門、資訊部、乙方組成聯合團隊，總裁掛專案組長，資訊部主導、企管部輔助。目前，資訊部和乙方團隊人員已經確認，業務部門人員還未確認。計畫每個業務部門設定一名組長兩名關鍵使用者。
按照專案組織架構中的業務單元，我們去每個部門進行未來專案人員的確認，順便做專案啟動前的一次宣貫吧。
整個過程感覺不是太好，阻力很大，業務部門的負責人都守著一畝三分地，考慮自身的工作情況、各種理由推脫，不願意出人擔責任，甚至有的直接說沒時間沒人。即使拿著總經理已經批准的專案立項報告，還有未來專案上線後的獎金承諾，也無濟於事，最終，還有一半的業務部門，未提供明確的關鍵使用者（業務組長預設必須是業務部門負責人）。
這個問題在專案管理中，屬於專案干係人管理和資源管理，當然也算一種風險，組內討論解決方案如下：
1、繼續與業務部門溝通，至少要確定一名關鍵使用者，並保證專案期間的出勤時間達到40%；
2、將問題向上反饋，通過高層指派任務到各個業務部門負責人處；
3、制定人員不到位情況下的風險應對計畫；
4、制定專案制度，並請企管部嚴格按照制度考核專案組，必要時殺雞儆猴，力求保證專案資源穩定；
在確認關鍵使用者的過程中，還發現了另外乙個問題，就是由於企業屬於夕陽產業，各業務部門負責人大多是年紀偏大，價值觀和思維都比較落後的老員工，固執又偏執，完全不明白為什麼要上bpr，解釋說明也完全不care，他們自己這麼多年的經驗已經形成一套固有的思維模式，加上位高權重，本身有一股子打不倒的自信，很難說服，以前的專案也會出現一小撮這樣的阻力，但是，這個企業的阻力這麼多，是沒有想到的，可能跟行業有關係吧。
總結，今天出現兩個風險點，需要記錄並規劃解決方案。
1、資源不到位，業務部門參與度不夠；
2、bpr意識薄弱，業務部門關注度低，最終也會導致參與度不夠。
遊說溝通還是高層強壓，這是個問題。
有點出師未捷身先死的感覺，哈哈。不過這種情況也正常，所有專案都不會一帆風順，慢慢來吧。
之二 組建團隊
用了這麼正經的乙個詞來做標題，我就盡量寫點專業術語吧。這一直是我的弱項 我覺得我們完全是空手套白狼，按照 的話來說，就是 技術不是問題，關鍵是態度 當時我東拼 西湊，還到我們學校的論壇上，給那些回過一些帖子的人說 你好，我想和你 net的問題，qq 後來才發現，那些人幾乎都是大四的，後來只好憑藉在很...
測試專案過程 專案團隊組建
在軟體行業就重要的因素，那就是人，如果離開了人，或者更準確的說是人才，那麼軟體行業就無法生存。可以毫不誇張的說，軟體行業成也是人，敗也是人 而測試是軟體行業的乙個重要分支，自然離不開人。所以做乙個專案的測試工作，第一步，也是最重要的一步就是測試團隊的組建。下面我們來詳細說說，軟體測試團隊裡面應該有哪...
BPR專案實施5 業務現狀具現
經過兩周的業務調研，收集並梳理了各個部門的部門職能 崗位職責 流程 制度等基礎的業務資訊，接下來要做的事，是通過業務建模將公司的業務現狀具象化，即以流程框架的形式表現出來。這個過程主要分為以下幾個步驟 1 流程框架總圖設計 2 業務流程圖繪製 流程框架總圖根據前文的介紹，是在公司的業務基礎之上，結合...