許蕾

1、目的：為了簡(jiǎn)化審批節(jié)點(diǎn)，縮短審批周期，提升OA審批效率，提高業(yè)務(wù)用戶滿意度，理清流程，明確職責(zé)。

2、方法：分析OA用戶需求處理、需求實(shí)現(xiàn)、運(yùn)維工單管理、OA運(yùn)營分析全過程。

3、結(jié)果：實(shí)現(xiàn)從OA需求接收到開發(fā)上線的全生命周期管理。

4、結(jié)論：使電子行業(yè)某公司全體OA用戶，實(shí)現(xiàn)OA全過程流程化管理，高效運(yùn)作。

關(guān)鍵詞：OA、管理、流程。

1.定義

1.1需求提出人：基于日常業(yè)務(wù)運(yùn)作過程的問題、痛點(diǎn)或者需求，業(yè)務(wù)用戶作為需求提出人可提出OA需求。

1.2業(yè)務(wù)領(lǐng)域OA需求接口人：由各業(yè)務(wù)領(lǐng)域指定1名需求對(duì)接人，負(fù)責(zé)本領(lǐng)域需求收集分析、跨流程需求分析、體系文件提交審批受控，與OA BA直接對(duì)接，實(shí)現(xiàn)需求歸口管理。

1.3 OA BA（業(yè)務(wù)分析師）：對(duì)外與各業(yè)務(wù)領(lǐng)域需求接口人一起理解與分析業(yè)務(wù)需求;對(duì)內(nèi)負(fù)責(zé)OA IT方案設(shè)計(jì)及IT需求輸出，與開發(fā)工程師交接清楚，保障需求滿足預(yù)期的實(shí)現(xiàn)。

1.4 OA開發(fā)工程師：需求分析階段，協(xié)助BA提供技術(shù)支持;需求實(shí)現(xiàn)階段，與BA對(duì)接IT需求清單與需求規(guī)格，充分了解需求后，按預(yù)定的計(jì)劃負(fù)責(zé)在OA系統(tǒng)配置與功能開發(fā)并完成自測(cè)，確保按時(shí)按質(zhì)交付。

1.5 OA運(yùn)維工程師：負(fù)責(zé)業(yè)務(wù)用戶日常OA問題的接收與及時(shí)處理，保障OA系統(tǒng)的平穩(wěn)高效運(yùn)轉(zhuǎn)。

1.6同業(yè)務(wù)領(lǐng)域：OA按流程類型劃分業(yè)務(wù)領(lǐng)域，包括財(cái)務(wù)管理、人力資源管理、IT服務(wù)支持、研發(fā)管理、供應(yīng)商及采購管理、供應(yīng)管理、質(zhì)量管理、項(xiàng)目管理、行政管理、制造工廠、銷售管理、法務(wù)管理、資金管理、外包管理、黃石酒店管理。

1.7跨業(yè)務(wù)領(lǐng)域：涉及2個(gè)及以上業(yè)務(wù)領(lǐng)域，跨業(yè)務(wù)領(lǐng)域提需求是指某一業(yè)務(wù)領(lǐng)域或部門作為需求提出人提出需求，然后需求接收領(lǐng)域的需求接口人負(fù)責(zé)分析與管理需求。

1.8 OA需求評(píng)審團(tuán)隊(duì)由流程管理部總監(jiān)、OA BA代表、OA開發(fā)工程師代表、業(yè)務(wù)領(lǐng)域需求接口人、業(yè)務(wù)領(lǐng)域部門總監(jiān)等組成，負(fù)責(zé)對(duì)OA需求進(jìn)行評(píng)審并給出評(píng)審意見。

2.職責(zé)

2.1流程管理部

2.1.1負(fù)責(zé)0A管理辦法制定，以及對(duì)本管理辦法執(zhí)行情況進(jìn)行檢查、考核。

2.1.2承接與澄清OA需求，負(fù)責(zé)OA系統(tǒng)設(shè)計(jì)、配置、開發(fā)、優(yōu)化。

2.1.3負(fù)責(zé)OA系統(tǒng)運(yùn)營分析與發(fā)現(xiàn)問題，定期主動(dòng)向各業(yè)務(wù)領(lǐng)域收集問題、分析問題，按重要程度將問題清單進(jìn)行優(yōu)先級(jí)排序，形成計(jì)劃，并按期解決交付。

2.1.4負(fù)責(zé)及時(shí)處理解答0A系統(tǒng)運(yùn)行過程中用戶提出的各種運(yùn)維問題。

2.1.5負(fù)責(zé)OA管理辦法的宣貫、培訓(xùn)。

2.2基礎(chǔ)運(yùn)維管理部

2.2.1負(fù)責(zé)OA系統(tǒng)服務(wù)器、網(wǎng)絡(luò)、升級(jí)等運(yùn)維工作，保障系統(tǒng)運(yùn)行與安全。

2.3各業(yè)務(wù)領(lǐng)域的責(zé)任部門

2.3.1負(fù)責(zé)定期收集本領(lǐng)域的需求，并分析其合理性、業(yè)務(wù)方案可行性，評(píng)估價(jià)值收益。

2.3.2負(fù)責(zé)分析跨領(lǐng)域需求的合理性、業(yè)務(wù)方案可行性，評(píng)估價(jià)值收益。

2.3.3負(fù)責(zé)組織協(xié)調(diào)需求提出人、業(yè)務(wù)專家一起討論與輸出業(yè)務(wù)方案。

2.3.4負(fù)責(zé)新建或者優(yōu)化流程的體系文件提交審批受控。

3. 工作細(xì)則

3.1 OA需求處理

3.1.1需求收集

3.1.1.1各業(yè)務(wù)領(lǐng)域OA需求接口人定期主動(dòng)收集本領(lǐng)域需求。表單如下：

序號(hào) 業(yè)務(wù)領(lǐng)域 需求簡(jiǎn)稱 需求描述 價(jià)值收益 期望實(shí)現(xiàn)日期 需求優(yōu)先級(jí) 需求提出人 需求部門 提報(bào)時(shí)間

3.1.1.2基于日常業(yè)務(wù)運(yùn)作過程的問題、痛點(diǎn)或者需求，業(yè)務(wù)用戶作為需求提出人提出需求，包括需求名稱、需求詳細(xì)描述、需求價(jià)值收益、需求期望實(shí)現(xiàn)日期等信息。

3.1.1.3涉及跨領(lǐng)域或跨一級(jí)部門的需求，需征得需求提出人的部門總監(jiān)審批確認(rèn)（郵件或者正式簽批文件），要確認(rèn)其合理性、業(yè)務(wù)可行性，評(píng)估價(jià)值收益。同一級(jí)部門或同業(yè)務(wù)領(lǐng)域的需求，不需要需求提出人的部門總監(jiān)審批確認(rèn)。

3.1.1.4各業(yè)務(wù)領(lǐng)域需求接口人進(jìn)行初步分析，包括本領(lǐng)域與跨領(lǐng)域的需求，要分析其合理性、業(yè)務(wù)可行性，評(píng)估價(jià)值收益。需征得需求接口人的部門總監(jiān)審批確認(rèn)（郵件或者正式簽批文件）。

3.1.2需求分析

3.1.2.1 OA BA負(fù)責(zé)與各業(yè)務(wù)領(lǐng)域需求接口人澄清與分析需求，要分析需求的合理性、技術(shù)可行性，給出需求分析報(bào)告，包括業(yè)務(wù)現(xiàn)狀、需求描述與分析、業(yè)務(wù)痛點(diǎn)、根因、業(yè)務(wù)需求、優(yōu)先級(jí)排序、解決方案。

3.1.3需求評(píng)審

3.1.3.1 OA需求評(píng)審團(tuán)隊(duì)負(fù)責(zé)對(duì)需求進(jìn)行評(píng)審，包括需求的合理性、方案可行性、需求優(yōu)先級(jí)及投資收益，給出評(píng)審意見，包括需求駁回、需求接受、需求實(shí)現(xiàn)方案選擇、需求人天。

3.1.3.2涉及跨應(yīng)用系統(tǒng)需求，需IT需求與變革項(xiàng)目評(píng)審會(huì)評(píng)審。

3.1.3.3 OA BA負(fù)責(zé)OA需求的全生命周期管理，跟蹤需求狀態(tài)，與各需求接口人定期溝通進(jìn)展。

3.2 OA需求實(shí)現(xiàn)

3.2.1 IT方案設(shè)計(jì)

3.2.1.1根據(jù)已接受需求與業(yè)務(wù)方案，OA BA整理輸出需求的功能清單，及各功能的需求規(guī)格說明書，并得到業(yè)務(wù)部門認(rèn)可。包括目的、范圍、需求確認(rèn)說明等。明確變革項(xiàng)目需求、便于用戶、分析人員和開發(fā)人員進(jìn)行理解和交流以及功能的實(shí)現(xiàn)和識(shí)別，明確需求階段各相關(guān)角色、后續(xù)開發(fā)的依據(jù)，用戶驗(yàn)收的依據(jù)，確保交付質(zhì)量和按時(shí)交付，支撐項(xiàng)目階段目標(biāo)的達(dá)成。

3.2.1.2根據(jù)IT需求清單，OA BA負(fù)責(zé)與開發(fā)工程師、測(cè)試工程師確認(rèn)需求排期，并與需求接口人達(dá)成一致意見。

3.2.1.3 OA BA負(fù)責(zé)與OA 開發(fā)工程師交接清楚IT需求清單，并跟蹤OA開發(fā)進(jìn)度。

3.2.1.4針對(duì)新增或修改流程發(fā)布，OA需求接口人發(fā)起《體系文件審批單》，提交需求。（OA需求類型與流程對(duì)應(yīng)）。

3.2.2流程配置與功能開發(fā)及測(cè)試

3.2.2.1開發(fā)工程師在實(shí)施開發(fā)前應(yīng)仔細(xì)查看需求文檔，了解清楚用戶的需求，有任何疑問都要及時(shí)與BA確認(rèn)，確認(rèn)清楚之前不可進(jìn)行開發(fā)，防止做出來的產(chǎn)品與用戶需求不一致。

3.2.2.2需求開發(fā)統(tǒng)一先在OA開發(fā)環(huán)境上。若是簡(jiǎn)單需求，如增加表單字段，修改流程節(jié)點(diǎn)等需自測(cè)通過后，再在OA正式機(jī)進(jìn)行開發(fā)部署。若是較復(fù)雜需求，如涉及外部接口，涉及表單代碼控制等，自測(cè)完成后需經(jīng)過需求用戶進(jìn)行測(cè)試驗(yàn)證后方可上傳正式機(jī)開發(fā)部署。

3.2.2.3開發(fā)工程師在新建流程或接口時(shí)，若涉及到代碼編寫應(yīng)注意代碼規(guī)范，要代碼注釋，以便后續(xù)運(yùn)維修改時(shí)能很快定位問題（如圖一），若修改原有代碼時(shí)在代碼中要注明修改內(nèi)容、修改日期、修改人等信息（如圖二）。

3.2.2.6涉及泛微升級(jí)包更新，開發(fā)工程師要先在測(cè)試機(jī)更新測(cè)試，輸出測(cè)試報(bào)告，驗(yàn)證通過后，由服務(wù)器運(yùn)維工程師負(fù)責(zé)正式機(jī)更新，更新時(shí)要做好文件及數(shù)據(jù)庫備份。

3.2.2.7在開發(fā)過程中，涉及修改服務(wù)器的公用文件時(shí)，修改前iGet獲取最新版本文件，進(jìn)行修改，并在代碼文件中備注修改內(nèi)容，不可在本機(jī)上歷史文件上進(jìn)行修改，防止可能出現(xiàn)多人修改替換他人修改內(nèi)容。

3.2.2.8完成開發(fā)后，將涉及代碼文件及相關(guān)需求文檔上傳至SVN系統(tǒng)，便于版本控制，供其他人參考使用。

3.2.2.9體系文件類需求類，OA測(cè)試工程師在承諾時(shí)間內(nèi)完成測(cè)試。

3.2.3驗(yàn)收上線運(yùn)行

3.2.3.1 OA測(cè)試通過之后，提交用戶UAT測(cè)試，OA BA負(fù)責(zé)組織需求接口人測(cè)試。

3.2.3.2需求接口人需輸出UAT測(cè)試報(bào)告并簽字。

3.2.3.3 UAT測(cè)試通過后，OA開發(fā)部署正式系統(tǒng)。

3.2.3.4需求評(píng)審管理團(tuán)隊(duì)對(duì)需求上線進(jìn)行評(píng)審，評(píng)審?fù)ㄟ^后OA BA負(fù)責(zé)啟用上線運(yùn)行

3.3 OA運(yùn)維工單管理

3.3.1日常業(yè)務(wù)操作過程中，業(yè)務(wù)用戶碰到運(yùn)維問題可提交《OA運(yùn)維工單》。OA運(yùn)維工程師負(fù)責(zé)問題及時(shí)處理，最終業(yè)務(wù)用戶確認(rèn)問題是否解決并關(guān)閉。

3.3.2 OA BA要定期分析問題清單，找到根因或者優(yōu)化點(diǎn)，優(yōu)化流程與系統(tǒng)。

3.3.3業(yè)務(wù)用戶碰到運(yùn)維問題也可以撥打IT運(yùn)維熱線。

3.4 OA運(yùn)營分析

3.4.1運(yùn)營報(bào)告包括不僅限于OA上線情況總覽、超長(zhǎng)期未處理OA流程清單、流程提交頻次排名前10、流程審批總時(shí)長(zhǎng)排名前10、流程節(jié)點(diǎn)審批時(shí)長(zhǎng)排名前10。

3.4.2按運(yùn)營報(bào)告按月由OA團(tuán)隊(duì)面向全員發(fā)布。

3.4.3基于運(yùn)營報(bào)告，OA BA負(fù)責(zé)與需求接口人協(xié)同推進(jìn)流程優(yōu)化及問題解決。

3.4.4 OA BA定期通過問卷等形式收集問題與需求。

3.4.5流程優(yōu)化成為組織一項(xiàng)例行化工作，解放高層管理者，打造高效的職業(yè)化團(tuán)隊(duì)，構(gòu)建運(yùn)營商的競(jìng)爭(zhēng)優(yōu)勢(shì)。

3.5 OA授權(quán)管理

3.5.1 OA授權(quán)管理原則

（1）一個(gè)接口：集團(tuán)各職能部門之間，每個(gè)單項(xiàng)流程在每個(gè)部門只允許有一個(gè)接口，實(shí)現(xiàn)流程在各部門的單點(diǎn)接觸，流程在各部門內(nèi)部的流轉(zhuǎn)由各部門負(fù)責(zé)進(jìn)行處理。

（2）一個(gè)工作日簽批（反饋）：每個(gè)流程控制點(diǎn)的停留時(shí)間最多一天。

（3）三個(gè)簽批控制點(diǎn)：每個(gè)單項(xiàng)流程原則上為三個(gè)簽批控制點(diǎn)，超過三個(gè)簽批控制點(diǎn)的特殊流程倡導(dǎo)自主改善，盡可能壓縮簽批空間，并對(duì)相關(guān)簽批控制點(diǎn)予以刪減。

（4）一個(gè)工作日反饋：對(duì)于下達(dá)的工作任務(wù)在一個(gè)工作日內(nèi)響應(yīng)，向相關(guān)部門反饋執(zhí)行或解決的時(shí)間進(jìn)度。

3.5.2 OA授權(quán)管理目的

（1）明確各層面的授權(quán)內(nèi)容，明晰各事項(xiàng)的審批核決程序，實(shí)現(xiàn)權(quán)責(zé)匹配，減少模糊地帶。

（2）優(yōu)化權(quán)利分配，釋放高層精力，培養(yǎng)公司的經(jīng)營管理能力，平衡經(jīng)營風(fēng)險(xiǎn)和開發(fā)效率。

（3）優(yōu)化審批程序，減少過程中的等待，減少過程的不規(guī)范，提高整個(gè)授權(quán)的效率。

3.5.3 OA加強(qiáng)審批以外的管理手段

（1）事前規(guī)范性控制：預(yù)算、目標(biāo)、計(jì)劃、人力資源編制控制。

（2）事中檢查控制：關(guān)鍵節(jié)點(diǎn)提報(bào)、項(xiàng)目公司定期、不定期報(bào)告。

（3）事后獎(jiǎng)懲的威懾性控制：內(nèi)部審計(jì)、考核。

3.5.4 OA授權(quán)集權(quán)和分權(quán)

集權(quán)、分權(quán)的最基本原則，就是“責(zé)權(quán)利”對(duì)等原則，要什么權(quán)，就要擔(dān)什么責(zé)，拿什么利。

一個(gè)結(jié)合：權(quán)責(zé)利相統(tǒng)一的集權(quán)和分權(quán)相結(jié)合。

十個(gè)放開：在結(jié)構(gòu)設(shè)置權(quán)、基層干部的考核任免權(quán)、勞動(dòng)用工權(quán)、專業(yè)技術(shù)人員聘用權(quán)、員工分配權(quán)、預(yù)算內(nèi)和標(biāo)準(zhǔn)內(nèi)費(fèi)用開支權(quán)、項(xiàng)目實(shí)施權(quán)、生產(chǎn)組織權(quán)、采購供應(yīng)權(quán)、銷售權(quán)10項(xiàng)基礎(chǔ)權(quán)利下放。

四個(gè)強(qiáng)化：強(qiáng)化預(yù)算管理、強(qiáng)化考核、強(qiáng)化審計(jì)監(jiān)督、強(qiáng)化服務(wù)。

七個(gè)管?。汗茏∧繕?biāo)、管住資金、管住資產(chǎn)、管住投資、管住發(fā)展戰(zhàn)略、管住政策、管住職能部門負(fù)責(zé)人。

4. 附錄

4.1 OA運(yùn)維工單處理流程圖

4.2 OA需求處理與開發(fā)管理流程圖

參考文獻(xiàn)：

[1]《跟我們學(xué)建流程體系》

[2]《贏在升級(jí)打造流程化組織》

[3]楊曉東，于常印.中國管理咨詢業(yè)實(shí)戰(zhàn)名家.北京：中國財(cái)政經(jīng)濟(jì)出版社，2019.

[4]菲利普.科比.流程思維：企業(yè)可持續(xù)改進(jìn)實(shí)踐指南.肖舒蕓，譯.北京：人民郵電出版社，2018.

[5]流程優(yōu)化要解決好認(rèn)識(shí)問題[J].司永江.中國郵政.2011（06）

[6]流程優(yōu)化帶來管理創(chuàng)新[J].楊冠立，呂勇.中國郵政.2011（11）