某省移動業(yè)務(wù)支撐系統(tǒng)業(yè)務(wù)與體系規(guī)劃項目-對業(yè)務(wù)需求管理和組織結(jié)構(gòu)的建議

1、某省移動業(yè)務(wù)支撐系統(tǒng)業(yè)務(wù)與體系規(guī)劃項目,,對業(yè)務(wù)需求管理和組織結(jié)構(gòu)的一些建議,,目錄,需求管理,需求管理的重要性,滿足業(yè)務(wù)需求是業(yè)務(wù)支撐部門的主要職能之一支撐能力的強弱表現(xiàn)在需求的滿足比率、及時性、合格率及需求的成本收益情況,業(yè)務(wù)支撐系統(tǒng)已經(jīng)越來越成為某省移動的核心能力，業(yè)務(wù)的創(chuàng)新和改進已經(jīng)離不開業(yè)務(wù)支撐系統(tǒng)的支持快速市場響應(yīng)能力越來越成為市場競爭的制勝因素，實際上就是對新需求的快速支撐能力,需求管理的重要性表現(xiàn)在四個方面：,,具體

2、分析：,對業(yè)務(wù)發(fā)展產(chǎn)生直接影響,是業(yè)務(wù)支撐能力的重要表現(xiàn),需求實現(xiàn)要投入大量的人力、物力、財力，需要加強成本管理需求實現(xiàn)的資源是有限的，需要加強需求質(zhì)量控制和優(yōu)先級管理，確保“好鋼用在刀刃上”。,需求實現(xiàn)是一種“稀缺資源”,全省集中的支撐系統(tǒng)必然要求全省集中、統(tǒng)一的需求管理，那么需求的實現(xiàn)將對全省的業(yè)務(wù)開展造成影響如何既能夠滿足省級業(yè)務(wù)需求能夠統(tǒng)一、有效的在各地市推廣，又可以及時滿足各地市差異化的需求做好全省集中、統(tǒng)一的需求管理，

3、需要省各業(yè)務(wù)部門、各地市分公司和業(yè)務(wù)支撐部門的共同努力,全省集中、統(tǒng)一的需求管理,需求管理的復雜性,需求來源多,多開發(fā)商管理,,,,,,需求確認,需求分析,需求實現(xiàn),需求評估,需求交付,,需求產(chǎn)生,,需求優(yōu)化,,跨多個知識域,涉及市場營銷、移動業(yè)務(wù)、IT技術(shù)、通信技術(shù)、項目管理等多方面知識對人員的經(jīng)驗積累要求高,需求管理生命周期,多個開發(fā)商/聯(lián)合體（A、B）的協(xié)調(diào)、合作、考核、激勵,BOSS智能網(wǎng)網(wǎng)站管理經(jīng)分系統(tǒng),需求管理的整個

4、生命周期包括6個二級流程，25個三級流程（詳見需求管理流程分析）,流程復雜,需求類別多,功能優(yōu)化功能擴展新業(yè)務(wù)需求流程優(yōu)化,溝通涉及到十幾個部門/科室,多部門協(xié)同,集團公司省公司地市公司支撐部門內(nèi)部,跨多系統(tǒng)開發(fā),實現(xiàn)要求高,需求數(shù)量多要求快速支撐,從05年12月至06年5月，有65％的需求提交超過1個月才進入版本，31％超過2個月，5％超過3個月實際版本的實現(xiàn)時間也往往超過預定時間有的需求從提出到最終上線超過5個月

5、對需求管理各環(huán)節(jié)缺乏時間跟蹤和評估,需求實現(xiàn)周期長,從業(yè)務(wù)的視角反映出需求管理中存在的問題,需求管理各環(huán)節(jié)間，缺乏明確的職責定義和輸出成果的定義，無法保證整個過程中對需求理解的一致性需求實現(xiàn)過程是“黑箱的”，只有在上線后，才暴露出開發(fā)結(jié)果與實際需求不符有時由于上線時間緊，不做測試或測試不充分，導致開發(fā)結(jié)果質(zhì)量控制不嚴,開發(fā)結(jié)果與需求不符合,需求滿足率低,近8個月來，各地市提出的需求占總需求的74％，而進入版本的不到60％排入版本的

6、地市需求占比還在降低，前四個月（05.10－06.01）占64％，近四個月（06.02－06.05）降到僅占50％,地市差異化需求滿足差,從05年12月至06年5月，省和各地市一共提出需求656個，進入版本258個，不足40％廣州市調(diào)研反映其需求滿足率<50％，其它地市更低因為需求難以滿足，各地市已大幅減少了需求的提出,數(shù)據(jù)來源：省業(yè)務(wù)支撐中心AMS系統(tǒng),存在問題,需求管理流程的具體問題分析,一級流程:,需求確認,需求分析,需

7、求實現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,二級流程:,需求描述不清楚，沒有嚴格遵守需求說明文件，且需求說明文件的描述范圍和詳細程度等指標有待進一步優(yōu)化需求申請后仍多次修改，需求確認往復多次需求申請沒有成本考慮，所以往往提出的需求數(shù)量偏多需求沒有投資收益分析，能帶來多少價值不清楚需求優(yōu)先級的確定沒有衡量標準及責任部門，各業(yè)務(wù)部門往往夸大需求的重要性和緊迫性，有時依靠領(lǐng)導拍板,業(yè)務(wù)支撐中心資源投入不足，難以及時處理眾多需求技

8、術(shù)部門與業(yè)務(wù)部門之間缺少有效溝通，存在理解的偏差，系統(tǒng)需求有時不能符合業(yè)務(wù)原來的要求技術(shù)部門與業(yè)務(wù)部門的職能劃分上欠明確技術(shù)室對需求復雜度評估沒有權(quán)威性，開發(fā)商在開發(fā)成本確定上相對處于強勢對需求缺乏抽象、前瞻性考慮，導致開發(fā)零散，缺乏系統(tǒng)的規(guī)劃,開發(fā)商的資源投入不足與開發(fā)商缺乏長期戰(zhàn)略合作模式，開發(fā)商缺乏優(yōu)化系統(tǒng)架構(gòu)的動力開發(fā)商主要定位在系統(tǒng)開發(fā)、運營維護，對需求分析參與不足多個開發(fā)商間的職責劃分尚不明確,沒有完善的測試體系

9、和完整的測試平臺系統(tǒng)測試不充分，測試報告不全地市只能測試本市需求，不能測試全省范圍的需求和對外接口需求測試資源不配套省提出的部分需求缺少與各地市的溝通，其適用性低，各地市推廣積極性低,需求上線后缺乏正式的交接過程，運維缺乏對需求開發(fā)質(zhì)量進行評估缺少需求上線情況分析缺少業(yè)務(wù)運行情況、收益及問題原因分析,沒有建立一整套的針對省、各地市、各部門及全員的“持續(xù)改進”激勵制度沒有真正形成需求管理閉環(huán)流程,各步驟具體問題分析:,為了保

10、證需求管理的高效順暢，需要從以下幾個方面加以保證：,需求管理全程流程,需求確認,需求分析,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,二級流程,需求優(yōu)化,系統(tǒng)架構(gòu)優(yōu)化,需求管理過程優(yōu)化,業(yè)務(wù)模型優(yōu)化,結(jié)束,需求提出,需求評估,收益/風險預測,需求提交,開始,需求調(diào)研,,,,,,需求審計,,,,,,,,,,,,,,,,,,需求管理流程,各方角色定位,控制指標和控制點,需求進行分類評估,開發(fā)商管理,開發(fā)、測試、生產(chǎn)三大環(huán)境分離,,三級流程,,,

11、,需求管理流程分解－－需求確認,需求提出,需求調(diào)研,需求評估,收益/風險預測,各地市提出地市需求省各業(yè)務(wù)部門提出的需求集團下發(fā)規(guī)范中的需求支撐內(nèi)部提出完善的需求其它系統(tǒng)改造產(chǎn)生的需求,對需求實現(xiàn)后所能帶來的價值進行預測分析，即收益分析對新需求可能存在的風險進行分析,業(yè)務(wù)部門對需求的重要性和緊迫性進行分析，評估需求業(yè)務(wù)優(yōu)先級對需求的合理性、與其它業(yè)務(wù)的關(guān)聯(lián)性、互斥性進行分析,對需求進行調(diào)研、細化，根據(jù)根據(jù)模板形成需形成需求調(diào)研

12、報告，對需求進行詳細描述,三級流程:,一級流程:,二級流程:,說明:,需求提交,確定需求是否需要實現(xiàn)（做還是不做），以及期望完成時間將明確的需求調(diào)研報告、需求評估報告和需求收益/風險預測提交業(yè)務(wù)支撐部門,成果：,需求確認,需求分析,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,,需求申請表,,需求調(diào)研報告,,需求評估報告,,需求收益/風險預測報告,,需求提交表,需求管理流程分解－－需求分析,一級流程:,二級流程:,需求確認,需求實

13、現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,業(yè)務(wù)需求分析,系統(tǒng)需求分析,需求復雜度分析,需求版本制定,對業(yè)務(wù)需求進行細化，分析對現(xiàn)有業(yè)務(wù)規(guī)范的影響，并提出對業(yè)務(wù)規(guī)范的修改建議方案業(yè)務(wù)可擴展性分析，對類似需求進行合并、抽象,結(jié)合需求業(yè)務(wù)優(yōu)先級評估和需求復雜度評估，進行需求排期，確定版本計劃,對需求內(nèi)容多少、難易程度、是否適合系統(tǒng)架構(gòu)等進行分析預測需求實現(xiàn)的工期和成本（工時）,對業(yè)務(wù)需求進行系統(tǒng)化分析，評估對現(xiàn)有系統(tǒng)架構(gòu)的影響，并提出需

14、求實現(xiàn)的初步建議方案,三級流程:,說明:,成果：,,業(yè)務(wù)需求分析書,,系統(tǒng)需求分析書,,需求復雜度分析書,,需求版本計劃,,需求分析,需求管理流程分解－－需求實現(xiàn),一級流程:,二級流程:,需求確認,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,設(shè)計,開發(fā),系統(tǒng)測試,明確系統(tǒng)需求和業(yè)務(wù)需求，對方案進行設(shè)計對設(shè)計方案進行評審制定測試計劃并設(shè)計測試方案,全面質(zhì)量管理的一環(huán)，對開發(fā)結(jié)果進行系統(tǒng)測試，從技術(shù)層面上把握質(zhì)量控制,制定開發(fā)計劃

15、及測試上線計劃對需求進行開發(fā)，管理開發(fā)質(zhì)量、進度,三級流程:,說明:,成果：,,設(shè)計方案方案評審表,,開發(fā)計劃測試上線計劃單元測試報告,,集成測試報告,需求分析,業(yè)務(wù)測試,全面質(zhì)量管理的一環(huán)，對開發(fā)結(jié)果進行業(yè)務(wù)測試，從業(yè)務(wù)使用層面上把握質(zhì)量控制,,業(yè)務(wù)測試報告,,正式上線,部署到正式環(huán)境進行測試，業(yè)務(wù)正式運行,,上線測試報告,需求管理流程分解－－需求交付,一級流程:,二級流程:,需求確認,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,

16、需求管理,三級流程:,說明:,成果：,需求分析,移交維護,系統(tǒng)培訓,業(yè)務(wù)推廣,將正式上線運行的功能模塊或系統(tǒng)，以及全部相關(guān)文檔移交給維護部門，由運維部門進行日常維護,新業(yè)務(wù)上線后，省和地市可以采取相應(yīng)的新業(yè)務(wù)推廣計劃,對省和地市公司的系統(tǒng)相關(guān)使用人員進行系統(tǒng)操作培訓,,移交確認文件需求上線通知單,,系統(tǒng)培訓計劃,,業(yè)務(wù)推廣計劃,評估需求完成的及時率、質(zhì)量、故障率等，并查找原因，提出改進措施核算需求實現(xiàn)的實際成本業(yè)務(wù)部門評審需求是否

17、達到預期目標,,需求審計報告,需求審計,,需求管理流程分解－－需求評估,一級流程:,二級流程:,需求確認,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,需求分析,業(yè)務(wù)情況分析,收益分析,改進建議,對業(yè)務(wù)運營情況進行定期的跟蹤、分析,對運營情況未能達到預期收益的新業(yè)務(wù)需求，進行根本原因分析（市場問題、需求實現(xiàn)的問題、業(yè)務(wù)推廣問題等），并對此業(yè)務(wù)提出應(yīng)對措施（改善、退出、保持等）,對需求的收益情況進行分析，并與需求申請時的需求收益預測進

18、行對比，評估需求提出的質(zhì)量,三級流程:,說明:,,業(yè)務(wù)運作情況分析報告,,收益分析報告,,改進建議報告,,成果：,需求管理流程分解－－需求優(yōu)化,需求優(yōu)化,系統(tǒng)架構(gòu)優(yōu)化,需求管理過程優(yōu)化,對某個或某類需求進行業(yè)務(wù)或系統(tǒng)層面的優(yōu)化,對需求申請、分析、開發(fā)、上線、評估、優(yōu)化的需求管理全過程進行優(yōu)化,根據(jù)已有的系統(tǒng)架構(gòu)修改建議，并考慮未來業(yè)務(wù)的變化和系統(tǒng)發(fā)展趨勢，對系統(tǒng)架構(gòu)進行優(yōu)化,三級流程:,說明:,業(yè)務(wù)模型優(yōu)化,根據(jù)已有的業(yè)務(wù)模型修改建議，

19、并考慮未來業(yè)務(wù)的變化，對業(yè)務(wù)模型進行優(yōu)化,一級流程:,二級流程:,需求確認,需求實現(xiàn),需求交付,需求評估,需求優(yōu)化,需求管理,需求分析,,需求優(yōu)化文件,,業(yè)務(wù)模型優(yōu)化文件,,系統(tǒng)架構(gòu)優(yōu)化文件,,需求管理過程優(yōu)化文件,成果：,,,“我不清楚誰最后作出決定"“我發(fā)現(xiàn)我應(yīng)該早點通知那個部門"“其實我可以提供參考建議，但是沒有人問我"“我覺得我有責任做這件事，但我沒有權(quán)限"“沒有人愿意進行決策&q

20、uot;“我做的事情應(yīng)當是別人的責任",RESPONSIBLE,執(zhí)行方－執(zhí)行某項任務(wù)的角色，可以多個執(zhí)行方共同執(zhí)行某項任務(wù),,ACCOUNTABLE,決策方－最終決策并負責的角色，一項任務(wù)只能存在一個決策方,,CONSULTED,參與方－在執(zhí)行某項任務(wù)時，或者做出最終決策前，被咨詢的角色,,INFORMED,知曉方－做出最終決策后或者執(zhí)行某項任務(wù)后，被通知的角色,,XXRACI模型,為了保證需求管理流程的高效順暢，需要明確各

21、方職責,RACI模型,在需求管理過程中各部門的職責（一）,,需求確認,需求提出,,業(yè)務(wù)活動,層級與部門,,需求調(diào)研,需求評估,,需求分析,業(yè)務(wù)需求分析,系統(tǒng)需求分析,收益/風險預測,需求提交,需求復雜度分析,,需求版本制定,,需求實現(xiàn),設(shè)計,,開發(fā),部署,系統(tǒng)測試,業(yè)務(wù)測試,,,,,,,,,A,R,C,A,R,A,R,A,R,A,R,C,A,R,A,R,A,R,A,R,A,R,C,I,A,R,A,R,A,R,A,R,A,R,A,R,A,

22、R,A,R,A,R,A,R,C,R,C,I,C,A,C,A,R,A,R,A,R,A,R,R,省業(yè)務(wù)部門,省業(yè)務(wù)支撐中心技術(shù)室,省業(yè)務(wù)支撐中心運維室,省業(yè)務(wù)支撐中心業(yè)務(wù)室,集團公司,,,I,A,R,A,R,A,R,A,R,C,A,C,C,I,A,C,A,C,,R,C,C,I,C,A,R,R,R,A,R,C,,,A,R,A,R,C,A,R,A,R,A,R,C,C,C,C,C,I,C,開發(fā)商,地市公司業(yè)務(wù)部門,地市公司業(yè)務(wù)支撐部門,,A,R,

23、A,R,,需求確認,需求提出,,,需求調(diào)研,需求評估,,需求分析,業(yè)務(wù)需求分析,系統(tǒng)需求分析,收益/風險預測,需求提交,需求復雜度分析,,需求版本制定,,需求實現(xiàn),設(shè)計,,開發(fā),正式上線,系統(tǒng)測試,業(yè)務(wù)測試,,,,,,,,,A*,R,C,A,R,A,R,C,A*,R,C,A,R,A*,R,A,R,A*,R,A,R,C,I,A*,R,C,C,C,A,R,C,C,C,C,A,R,C,C,A,I,A,A*,R,A*,R,A*,R,A*,R,A

24、*,R,,I,A,A,R,R,C,C,I,A,I,C,C,,R,R,R,I,R,A,R,A,R,R,R,R,,,A*,R,R,C,R,R,I,C,C,C,C,C,I,,C,注：A: 決策方（ACCOUNTABLE） R: 執(zhí)行方（ RESPONSIBLE ） C: 參與方（CONSULTED） I: 知曉方（INFORMED）,R,C,需求的提供可能會有多個來源，不同來源有不同的決策方，所以A*表示某一類需求的決策方,R,I,I,

25、I,I,I,I,,在需求管理過程中各部門的職責（二）,,I,C,I,R,I,,,R,R,R,R,R,R,C,C,開發(fā)商,地市公司業(yè)務(wù)部門,地市公司業(yè)務(wù)支撐部門,省業(yè)務(wù)部門,省業(yè)務(wù)支撐中心技術(shù)室,省業(yè)務(wù)支撐中心運維室,省業(yè)務(wù)支撐中心業(yè)務(wù)室,,,,,C,R,I,R,C,I,I,R,R,R,A*,R,C,R,R,R,A,R,C,R,R,C,A.R,C,A,R,C,A,R,A,R,A,R,A,R,C,A,R,,業(yè)務(wù)活動,層級與部門,,需求交付,

26、移交維護,,系統(tǒng)培訓,,需求評估,業(yè)務(wù)情況分析,收益分析,,需求審計,改進建議,,需求優(yōu)化,需求優(yōu)化,業(yè)務(wù)模型優(yōu)化,系統(tǒng)架構(gòu)優(yōu)化,,,,,,,,,需求管理過程優(yōu)化,,,A,R,A,R,A,R,R,A*,R,R,A*,R,C,C,C,R,C,C,C,RACI模型,注：A: 決策方（ACCOUNTABLE） R: 執(zhí)行方（ RESPONSIBLE ） C: 參與方（CONSULTED） I: 知曉方（INFORMED）,業(yè)務(wù)推廣,C,

27、I,C,R,R,R,需求的提供可能會有多個來源，不同來源有不同的決策方，所以A*表示某一類需求的決策方,C,通過分析RACI，得出一些結(jié)論,在需求分析階段，需要兩個部門共同負責完成需要實現(xiàn)過程對于業(yè)務(wù)室是”黑箱“的；而和業(yè)務(wù)部門的溝通對于技術(shù)室也是”黑箱“的誰對全過程的需求質(zhì)量負責？,業(yè)務(wù)室參與需求管理的全過程，并需要協(xié)調(diào)各相關(guān)各部門需求管理中，40％的活動由業(yè)務(wù)室負責（決策方）在需求上線后，業(yè)務(wù)室的后續(xù)工作尤為重要,結(jié)論,,說

28、明,業(yè)務(wù)室在需求管理中發(fā)揮重要作用,業(yè)務(wù)室和技術(shù)室的職責難以明確分離,業(yè)務(wù)部門決定需求的重要性、緊迫性，支撐部門決定需求的復雜性——由這兩方面共同決定需求如何實現(xiàn)（需求版本）業(yè)務(wù)部門要保證”好鋼用在刀刃上“，支撐部門通過“收益分析”過程進行監(jiān)督支撐部門要保證”用在刀刃上的是好鋼“，業(yè)務(wù)部門通過”需求審計“過程進行監(jiān)督,業(yè)務(wù)和支撐共同努力并相互監(jiān)督,對開發(fā)商缺乏統(tǒng)一的質(zhì)量管理策略,需求最終是由開發(fā)商開發(fā)完成的，而且開發(fā)商將參與更多的需

29、求管理活動但技術(shù)室負責開發(fā)商的考核和管理，但業(yè)務(wù)室負責需求的最終測試，如何考核開發(fā)商的需求開發(fā)質(zhì)量？,根據(jù)業(yè)務(wù)優(yōu)先級、系統(tǒng)實現(xiàn)復雜程度，對需求進行分類管理,,業(yè)務(wù)緊迫程度高中低,需求實現(xiàn),,,系統(tǒng)實現(xiàn)復雜程度高中低,,,,項目開發(fā)型,配置型,版本開發(fā)型,規(guī)劃開發(fā)型,集團下發(fā)的規(guī)范,1、BOSS1.5規(guī)劃和規(guī)范,省業(yè)務(wù)部門提出業(yè)務(wù)需求,2、關(guān)于BOSS渠道管理子系統(tǒng)接口開發(fā)需求3、營收稽查二期,地市公司提出業(yè)務(wù)需求,4

30、、分銷商電子易支付5、增加智能網(wǎng)預存話費優(yōu)惠功能,,支撐內(nèi)部提出改善需求,6、智能網(wǎng)客戶GPRS業(yè)務(wù)優(yōu)化7、清單查詢短信通知優(yōu)化,根據(jù)關(guān)鍵維度對需求進行分類評估，不同類型的需求，其響應(yīng)時間、需求實現(xiàn)的生命周期存在很大的差異,需求來源,需求分類舉例說明：,5,1,2,3,4,6,7,不同類型的需求，有著不同的實現(xiàn)過程和實現(xiàn)周期，應(yīng)通過不同方式實現(xiàn),提高系統(tǒng)靈活性、可擴展性,提高業(yè)務(wù)前瞻性、可規(guī)劃性,,,通過“定期版本開發(fā)方式”實現(xiàn),通

31、過“項目建設(shè)方式”實現(xiàn),當前，定期版本開發(fā)方式中存在的問題,活動,部門,,表示各部門負責的活動,存在問題,整個需求分析過程（2、3、4、5）聯(lián)系緊密，難以進行明確的職責劃分2、3、6都存在需求傳遞和需求理解的過程，導致協(xié)調(diào)的時間長，對需求理解產(chǎn)生偏差1－10各個環(huán)節(jié)，各部門各管一段，缺乏統(tǒng)一的需求管理，沒人對最終的需求質(zhì)量負責6－8由開發(fā)商負責，對業(yè)務(wù)室是“黑盒的”，直到9才發(fā)現(xiàn)問題，影響需求的質(zhì)量和上線時間,,,,,需求上線的時

32、間,影響,需求實現(xiàn)周期長需求質(zhì)量難以保證職責不明確資源得不到保障,,,對定期版本開發(fā)方式的改進建議,活動,部門,,表示各部門負責的活動,,,,,需求上線的時間,目標,,措施,穩(wěn)定,固定的版本上線周期，把版本開發(fā)變成日常工作設(shè)置固定職能負責版本開發(fā)，確保內(nèi)部資源穩(wěn)定與開發(fā)商簽訂長期合同，對開發(fā)商資源有明確要求，確保外部資源穩(wěn)定,,高效,減少中間環(huán)節(jié)，將串行方式改為Team方式由專人負責對需求進行全程管理，確保需求按時完成開發(fā)

33、商盡早參與需求分析過程，并有專職項目經(jīng)理控制版本進度,高質(zhì)量,由專人負責對需求進行全程管理、監(jiān)督，對需求的質(zhì)量負責將需求質(zhì)量要求量化，并與開發(fā)商績效掛鉤提高地市分公司參與程度，提供業(yè)務(wù)測試質(zhì)量,,,,當前，項目建設(shè)方式中存在的問題,活動,部門,,表示各部門負責的活動,存在問題,項目建設(shè)過程與版本開發(fā)過程有很大的區(qū)別（2－5），不能同樣對待可行性分析（2）目前由業(yè)務(wù)室完成，但其中也會討論技術(shù)可行性，甚至技術(shù)方案，但缺乏技術(shù)方面的支持

34、集團的規(guī)范直接由技術(shù)室負責實施，沒有充分考慮對業(yè)務(wù)的影響項目對資源的要求是突發(fā)的，由于項目建設(shè)和版本開發(fā)沒有有效分離，對資源的需求產(chǎn)生沖突，相互影響（包括開發(fā)商資源）,,,,,需求上線的時間,影響,項目目標不明確，沒有充分考慮業(yè)務(wù)目標項目中，業(yè)務(wù)與技術(shù)沒有很好的結(jié)合項目延期,,當前，項目建設(shè)方式中存在的問題,活動,部門,,表示各部門負責的活動,,目標,,措施,規(guī)劃性,項目應(yīng)該盡量按3年滾動規(guī)劃來實施,,按時保質(zhì),項目應(yīng)該有明確的

35、目標，明確的計劃，高質(zhì)量的項目管理——并按照項目計劃達到預期的目標,有效的資源管理,項目對資源的要求是動態(tài)的通過PMO做項目組合管理，保證資源的合理有效利用項目組是根據(jù)項目對資源的需求，由多個部門臨時組建的（包括開發(fā)商）,,,,,,,,需求上線的時間,目標,優(yōu)化全部項目組合，而不是對單個項目在統(tǒng)一的一套評估標準的基礎(chǔ)上，定義項目的優(yōu)先級保證關(guān)注的是公司的戰(zhàn)略目標和財務(wù)目標，而不是單個業(yè)務(wù)部門的目標通過建立項目組合管理的透明度，

36、對優(yōu)先級高的項目進行大力支持，保證其成功保證資源配置的效用和效率,,,,,戰(zhàn)略影響,高,,財務(wù)影響,低,低,高,,,,,,,,,項目A,項目B,項目C,項目D,項目F,項目E,,,預算控制基線2) 內(nèi)部資源/技能控制基線,2),1),,有效的項目組合管理是為了判別業(yè)務(wù)的優(yōu)先級、優(yōu)化投資,項目組合管理流程示例,需求管理對組織結(jié)構(gòu)的影響,業(yè)務(wù)支撐部,其它部門,,,,,新業(yè)務(wù)開發(fā),,,,,PMO,PM1,PM2,PM3,PM4,其它部門,

37、,,,,其它部門,,,,,,對組織結(jié)構(gòu)的建議將新業(yè)務(wù)開發(fā)（版本開發(fā)）和項目建設(shè)分離由固定的職能負責新業(yè)務(wù)開發(fā)的全流程，開發(fā)商也應(yīng)建立相應(yīng)的固定職能建立PMO負責項目的規(guī)劃和建設(shè)，根據(jù)項目情況臨時組建項目組，項目由項目經(jīng)理負責,為了保證需求管理的高效順暢，需要考慮增加以下控制點：,1、規(guī)定每月計劃內(nèi)上線2次，緊急上線1次，緊急上線需部門領(lǐng)導審批,3、每次上線后須進行回歸測試，確保上線穩(wěn)定,4、每項開發(fā)需求必須對維護人員進行培訓，確保

38、維護人員對系統(tǒng)新增功能的維護能力,,2、建有對立測試用例庫，每次上線逐步豐富測試用例庫中的測試用例，提升測試質(zhì)量,,,,,,需求確認,需求分析,需求實現(xiàn),需求評估,需求交付,,需求產(chǎn)生,,需求優(yōu)化,需求管理生命周期,為了保證需求管理的高效順暢，需要設(shè)置各項開發(fā)控制指標,1、開發(fā)故障次數(shù)當月（或近2月）因需求開發(fā)原因、程序原因?qū)е孪到y(tǒng)故障的次數(shù)2、開發(fā)成本/收益率對以往開發(fā)的需求（一般不超過4個月）可以評估其收益的，分析其成本/收益

39、率,1、開發(fā)及時率當月（或近2月）上線需求中按時需求數(shù)（需求實際上線時間早于等于需求計劃上線時間）/當月（或近2月）上線需求總數(shù),指標維度,,關(guān)鍵指標,開發(fā)效率,開發(fā)質(zhì)量,1、文檔提交及時率當月（或近2月）按時提交需求開發(fā)文檔的需求數(shù)/當月（或近2月）上線需求總數(shù)。需求文檔包括：需求、改造方案、單元測試報告、集成測試報告，業(yè)務(wù)測試報告2、代碼提交及時率當月（或近2月）按時提交代碼的需求數(shù)/當月（或近2月）上線需求總數(shù)3、缺陷修

40、復及時率當月（或近2月）按時修復集成測試中發(fā)現(xiàn)的程序缺陷數(shù)/當月（或近2月）集成測試中發(fā)現(xiàn)的程序缺陷總數(shù),開發(fā)規(guī)范,為了保證需求管理的高效順暢，需要全方位加強開發(fā)商管理,人員數(shù)量,人員資質(zhì),需求覆蓋率,測試BUG修復及時率,上線穩(wěn)定性（如：2次系統(tǒng)故障間平均時間）,系統(tǒng)可維護性（如：系統(tǒng)事故平均修復時間）,人員工作規(guī)范性,文檔完整率,文檔提交及時率,代碼提交及時率,開發(fā)及時率,問題解決及時率,負責程度,積極程度,合作程度,人員投入,開

41、發(fā)質(zhì)量,合作滿意度,支撐有效性,管理規(guī)范性,,,,,,開發(fā)維護成本/收益率分析,地市系統(tǒng)用戶滿意度,問題復發(fā)率,問題解決質(zhì)量指標（如：系統(tǒng)可用率增加率）,開發(fā)商管理維度：,關(guān)鍵指標：,為了保證需求管理的高效順暢，需要系統(tǒng)支撐的改進,不是所有流程都嚴格走AMS電子流 ，AMS系統(tǒng)數(shù)據(jù)并不精確 沒有嚴格規(guī)定的流程角色和職責定義，現(xiàn)在的流程的執(zhí)行者并不是按角色職責分配責任和權(quán)限的 AMS對應(yīng)的是舊的組織結(jié)構(gòu)，流程責任角色并不對應(yīng)新的組織

42、結(jié)構(gòu)，所以流程執(zhí)行的并不嚴謹 AMS對配置管理支持力度不夠，對系統(tǒng)資源的具體情況，狀態(tài)和審計歷史紀錄沒有詳細記錄，沒有和變更請求結(jié)合起來，配置項之間的關(guān)系看不到 變更管理，沒有明確的變更重要性評級活動和角色責任體制對開發(fā)商管理流程基本靠AMS，只能對開發(fā)商的開發(fā)結(jié)果作管控，對開發(fā)流程執(zhí)行度缺乏掌控 需求流程中，在需求評審前，沒有需求提出方對需求的再確認活動；評審只是支撐中心內(nèi)部流程，存在支撐中心和需求方對需求理解不一致，而

43、雙方都未意識到的情況,,流程執(zhí)行,配置管理,變更管理,運維流程,,升級AMS系統(tǒng)，使其工作流流程上的角色設(shè)置對應(yīng)相應(yīng)的現(xiàn)實組織結(jié)構(gòu) 在AMS中將角色職責進一步細分，比如需求業(yè)務(wù)分析專家，需求系統(tǒng)分析專家，等；在實際組織流程上，有相應(yīng)的人員分配到這些角色 AMS改進，對系統(tǒng)資源的具體情況，狀態(tài)和審計歷史紀錄，和其他配置項的關(guān)系，版本信息等作記錄和及時升級 AMS應(yīng)支持變更管理，采用類似變更單流程，對變更級別，變更參與角色，

44、變更影響等予以紀錄并分配相應(yīng)角色建議將開發(fā)商內(nèi)部開發(fā)測試流程關(guān)鍵步驟整合到AMS上，使開發(fā)流程對支撐中心更加透明 建議將如前所述的需求審計，改進建議和收益分析活動等加入到AMS需求單管理流程,改進方案,問題,,,BOSS系統(tǒng)開發(fā)建設(shè)人員,BOSS系統(tǒng)測試人員,BOSS系統(tǒng)維護人員,操作,操作,操作,代碼提交,版本發(fā)布,為確保BOSS系統(tǒng)的安全，開發(fā)、測試、生產(chǎn)三大環(huán)境需要在物理和人員上分離,舉例：系統(tǒng)建設(shè)開發(fā)人員不能訪問、操作生