第一篇：電力OA項目經驗

2009/4--2009/12： 電力公司投資（資金）計劃系統

項目描述： 該系統的實施目標是為了實現省電力公司對各市電力公司的投資計劃進行有效管控，并實現與

國網系統的數據交換。

責任描述： 承擔軟件實施工作，甘肅電力公司投資計劃項目、新疆電力公司投資計劃項目，工作職責：輔

助項目經理進行調研工作，負責數據收集、整理、系統安裝調試和培訓工作。

2008/5--2008/10 ：寧夏回族自治區SG186電力安全生產系統

項目描述：

責任描述：

2009/7--2010/2 ：吉林省SG186電力營銷業務應用系統

開發工具：

項目描述： PL/SQL+Oracle 吉林省SG186電力營銷業務應用系統推廣應用（業擴、抄表核算、收費賬務、用電檢查、計量、資產、線損、稽查）

責任描述：

國家電網SG186信息一體化營銷業務項目：負責項目前期系統的測試，系統推廣，需求調研、供電局相關人員培訓、參與編寫用戶手冊、系統上線后的維護工作及BUG反饋跟蹤。寧夏回族自治區SG186電力安全生產系統的實施及推廣 負責電力安全生產、系統應用的實施工作: 包括供電局的需求調研分析、業務流程及需求資料編寫整理、系統的部署調試、系統的測試（黑盒測試），供電局相關人員培訓、編寫用戶手冊、系統維護

2011/3--至今：山西省電力營銷費控系統

項目描述：

1、國家電網公司在2009年提出了全面建設智能電網的戰略規劃，隨后在2010年初又提出落實以全面推進

“三集五大”工作為核心的總體部署，提出加快統一堅強智能電網和“一強三優”現代公司建設，要求加快電力用戶用電信息采集系統建設。

2、為保證智能電網建設規范有序推進，國網公司提出了實現用電信息采集系統“全覆蓋、全采集、全費控”的總體建設目標。

3、發改委推行居民階梯電價，鼓勵居民節約用電、減少能源浪費，從而提高能源的利用效率。

4、以智能電表應用為起點，實現從單純電量采集向用戶側綜合數據采集、用戶用電管理的轉變，實現高效、經濟、智能化的電網應用 在此背景下，安裝智能表、開展費控業務以及陸續開展其它

提升應用是必然趨勢。山西電力公司率先開展費控業務研究，在和局方負責人員對于費控業務進行

充分討論以及對于營銷業務應用的改造影響詳細分析梳理的基礎上，提出本解決方案。

責任描述：

2008/6--2009/11： 安徽電力公司生產管理系統

開發工具： C++,DEPHI

項目描述： 在上海電力生產管理系統(PMS)基礎上本地化,分期實現對供電公司生產業務的管理,包括電網管

理設備臺帳管理及其它生產業務模塊管理

責任描述： 擔任實施工程師,按不同的模塊,在市級分公司完成試點實施后組織推廣到全省供電公司。先后

完成電網基礎數據錄入、缺陷管理、線損管理和供電方案答復等多個模塊的實施和推廣

2008/10--2009/12： 內蒙古旗縣農電局用電營銷軟件項目實施

項目描述： 該項目包括生產管理、用電營銷管理、業擴報裝、計量管理、人力資源、辦公自動化(OA)。

實施過程中負責:

1、軟件運行環境搭建。與農電局信息中心人員交流了解當地業務情況及當前數據庫的表結構。國家電網SG186信息一體化營銷費控系統項目：負責項目前期系統的測試，系統推廣，需求調研、供電局 相關人員培訓、參與編寫用戶手冊、系統上線后的維護工作及BUG反饋跟蹤。

2、將當前客戶系統的相關數據導入到本公司數據庫中。

請農電局生產部門人員在本系統中維護線路變壓器信息。

設置抄表員、核算員、收費員 及營銷部門其他人員權限。

2、統計用戶的打印票據，測試打印票據。

如果用戶有抄表機、集抄設備，與用戶及抄表和集抄廠家2方協調溝通，公司人員制作接口，實施人員測試接口程序。

3、導入用戶某個月的電能表表底，并計算電費，對新舊兩個系統所有用戶電費核對，電費有出入的情況和當地農電局人員協調溝通解決。

統計用戶報表格式。

4、抄、核、收滿足客戶要求后，與客戶協調，確定培訓時間、項目上線時間。

在規定時間對農電局各部門人員分批培訓，并簽培訓單、項目運行單。

項目雙周計劃及項目實施周報提交。

2009/7--2010/6： 江西雙源電力高新技術有限公司 | 研發部 | ERP技術/開發應用

IT服務（系統/數據/維護）/多領域經營、股份制企業、2001-4000元/月

負責國家電網江西電力公司的SAP MM物料管理模塊的實施，先后負責實施江西省吉

安市供電公司、江西省吉安市安福縣供電公司、江西省贛州市供電公司、江西省贛州市

大余縣供電公司的ERP SAP項目。

SAP功能強大，集成性高，MM是SAP的中間環節，月底與FICO財務進行月結，四

個供電公司的項目進展順利，現處于階段性項目驗收階段。

2009/9--至今： 黑龍江省電力公司ERP項目

項目描述： 國家電網公司依據國家“十一五”信息發展規劃，決定在國家電網公司系統構筑由信息網絡、數據交換、數據中心、應用集成、企業門戶五個部分組成的一體化企業級信息集成平臺；建設由財務（資金）管理、營銷管理、安全生產管理、協同辦公、人力資源管理、物資管理、項目管理和綜合管理八大業務應用；建立健全信息化安全防護、標準規范、管理調控、評價考核、技術研究、人才隊伍六個保障體系。重點建設“一個系統、二級中心、三層應用”。黑龍江省電力公司ERP項目作為國網公司“SG186”工程的一部分，起著推動公司信息化建設、提高企業管理水平的重要作用。

責任描述： 作為SAP(FICO)財務實施顧問，為黑龍江省電力公司進行ERP實施工作，主要負責西部推廣分區財務模塊實施工作，主要包括：

1、最終用戶培訓工作

2、靜態、動態數據清理與導入工作

3、模擬運行

4、上線支持工作

2009/2--2009/9： 湖北省電力公司ERP項目

項目描述： “SG186”工程是國網公司確定的“十一五”信息化建設的宏偉目標，它的具體內容包括企業一體化平臺、八大業務應用和六項信息化建設保障措施。湖北省電力公司ERP項目作為國網公司“SG186”工程的一部分，起著推動公司信息化建設、提高企業管理水平的重要作用。

責任描述： 作為SAP(FICO)財務實施顧問，為湖北省電力公司進行ERP實施工作，主要負責武漢推廣分區財務模塊的實施工作，主要包括：

1、項目前期業務調研與差異確認工作，業務藍圖設計

2、根據差異分析進行系統配置以及權限設計、配置與測試工作

3、系統配置手冊、操作手冊的編寫與修改工作

4、關鍵用戶、最終用戶培訓以及系統單元測試、集成測試

5、各靜態數據與動態數據收集與清理工作

日期:2011/03-2011/04

項目名稱/客戶名稱

開發環境與技術

項目簡述

本人職責 物11111111111111 WindowsXpWeb本人

第二篇：OA項目總結

組織機構管理模塊

請描述一下你做的組織機構管理模塊

描述思路：

1、組織機構模塊的基本需求

a)本模塊主要管理公司、子公司、部門、崗位、員工的信息 b)公司下面可以創建子公司、部門

c)部門下面可以創建子部門、崗位或員工

d)崗位下面可以創建員工（即員工可以屬于某個崗位）

e)公司、部門、崗位、員工形成一棵組織機構樹，要求使用樹型方式來展現和管理

2、組織機構的總體設計思路

a)公司、部門、崗位、員工可以看成同一種類型：Party b)在Party上實現樹型結構（父子關系）

c)其它類型：公司、部門、崗位、員工均繼承Party（請畫出類圖）

3、組織機構的實現技巧

a)利用jQuery的jsTree實現組織機構樹

b)利用jQuery的treeTable實現列表（AJAX、查詢、分頁）

c)在組織機構樹中顯示公司、部門、崗位的信息，點擊公司、部門、崗位，則可以顯示其詳細信息，及其下面的所有員工（利用hibernate filter避免在樹上顯示員工信息）

d)為了顯示某個公司或部門（包括其下級機構）下面的所有員工，我們設計了一個sn，這個sn根據組織機構的樹型結構來取值，通過它便可以方便實現查詢需求。e)利用TreadLocal實現分頁參數的傳輸

f)利用VO設計模式適應客戶端對數據格式的特殊要求

4、我們這個設計的優點在哪里

a)通過樹的方式來管理，一目了然，層次清楚

b)TheadLocal設計模式的運用大大降低了分頁查詢邏輯的封裝處理

c)抽象出Party來，便于對所有的組織機構實體進行統一的管理（比如方便我們后面的權限管理模塊把所有Party統一對待）

5、我們這個設計的缺點在哪里

a)沒有實現員工的調動管理（從一個部門調到另外一個部門），此功能在項目二期實現！

b)員工不允許跨部門（即一個員工只能屬于一個部門，而不能同時屬于多個部門）c)在模型上沒有規定哪些類型的Party只能放在哪些類型的Party下面，比如，在一般的需求中，崗位下面肯定是不能掛一個公司的。我們針對這種需求，是通過具體的代碼邏輯來實現的，而沒有辦法在一個地方去統一定義這種規則。i.如果要實現這些邏輯的統一定義，可以參考“責任模式”！

權限管理模塊

請描述一下你做的權限管理模塊

描述思路：

1、權限管理的基本需求

a)系統后臺有很多菜單項，同時各個頁面上也有很多功能按鈕，客戶要求我們的系統要能夠控制這些菜單項的訪問權限，也可以控制到具體每個功能按鈕的訪問權限 b)客戶要求建立角色的概念（參考RBAC），能夠自由定制不同的角色，角色和用戶之間是多對多的。

c)權限可以授予角色，然后把角色分配給用戶，這樣用戶就擁有了角色的權限 d)權限也可以授予某個部門、某個崗位，這樣在這些部門或崗位下面的用戶就擁有了這些部門和崗位的權限

e)客戶還要求權限也能直接授予用戶，這樣即使擁有相同的角色、相同的部門、相同的崗位，用戶的權限也可以是不同的

f)這樣，用戶自身被授予的權限、用戶擁有的角色的權限、用戶所屬部門或崗位的權限這些要素聯合起來判斷，才能最終決定用戶的權限。

g)因為用戶的權限可能從多個角色或部門、崗位中繼承下來，而這些角色、部門或崗位的授權極有可能會有沖突，比如一個角色的授權是允許訪問，而另外一個角色的授權是拒絕訪問，客戶要求，如果出現這種情況，就以拒絕為準，即不允許訪問。

2、權限管理的總體設計思路

a)因為權限可以被授予用戶、角色、部門、崗位等等，我們稱之為權限控制的“主體”，我們定義了一個接口Principal用來表示主體的概念，用戶、角色、部門、崗位等均實現這個接口

b)我們要控制菜單項以及各種功能按鈕的訪問，我們稱這些菜單項和各種功能按鈕為權限控制的“資源”，定義了一個SysResource接口來表示資源的概念。

c)菜單項是一種資源；而各種功能按鈕最終其實是要訪問后臺的某個類的某個方法，因此我們把Action類看成是一種資源（稱為“操作資源”），各種功能按鈕則對應了這個類里面的各種方法，我們把這些方法看成是這種資源的各種操作。d)我們定義了一個ACL用來表示哪些資源的哪些操作被授予了哪些主體，ACL中的主要屬性包括：主體類型（principalType）、主體ID(principalId)、資源類型(resourceType)、資源ID(resourceId)、操作狀態(aclState)，其中操作狀態是int類型，在Java中，一個int有32位（bit），我們定義資源的時候，把這個資源對應的操作映射到某一位上，規定在這一位上取1表示允許執行那個操作，而取0表示不允許執行那個操作。e)這樣，在授權的時候，我們直接改變相應操作的狀態位的取值即可；在認證的時候，直接判斷相應操作狀態位的取值

3、權限管理的實現技巧 a)在實現上，對于授權，我們界面上用jQuery和jQuery的插件jsTree來呈現菜單樹，在菜單樹的前面顯示一個CheckBox框，打勾表示允許，打叉表示拒絕；同時也做了一些右鍵點擊顯示上下文菜單，方便客戶執行各種功能

b)jsTree沒有打叉這種顯示方式，為了滿足我們的要求，所以對jsTree插件做了一些擴展（主要是修改它的js文件和css文件、圖片等），以便能支持更強大的顯示方式。

c)因為我們把系統中的各種Action類及其方法，看成是各種資源及其操作，為了方便管理，我們利用Spring提供的API搜索具備某些特征的Action類及其方法（特定的命名及特定的注解），將這些信息插入數據庫，這樣便可以將其用于授權和認證。

d)在認證的時候，我們實現了兩種方式的認證： i.第一是根據授權，能夠把沒有授權的菜單項屏蔽，也能夠把沒有授權的功能按鈕屏蔽； ii.第二，因為第一種認證方式會有一些安全性問題，比如客戶可以繞過功能按鈕，直接在瀏覽器輸入某個功能的地址，為了避免這種問題，我們在后臺也做了認證，根據當前請求的是哪個類的哪個方法，編寫攔截器，判斷當前登錄用戶是否具備這個權限，如果沒有這個權限，就不允許執行這個操作！

e)InitService和XML f)自定義注解，利用Springde的API掃描類（大概說出一兩個類名）

4、我們這個設計的優點在哪里

a)因為抽象出了主體和資源這兩個概念，核心的授權和認證代碼依賴于這兩個概念，而不是具體的哪個主體或資源。所以，能夠更靈活的支持主體和資源的擴展，比如假設以后客戶還想要給用戶分組，按照分組來給用戶授權，那么只需要實現一個新的主體類型即可，核心的授權和認證的代碼無需變化。

b)權限控制的粒度更細，因為我們用一個int來表示操作的允許狀態，這就意味著，我們能支持在某個資源上的至多32種操作，在設計上無需做變化。一個資源上的操作一般不會超過32種操作，一般來說也就是添加、更新、刪除、查詢，以及在這個基礎上更加細分的一些操作而已，很少會超過32種操作。即使是極端情況，超過了32種操作，那么我們的核心設計也無需變動，無非就是把int換成一個long類型即可（支持64種操作）。

c)我們還能支持細粒度的操作權限繼承關系： i.比如針對“公司管理”這種資源，假設它有六種操作：添加公司信息、刪除公司信息、更新公司信息、查詢公司信息、添加子公司、刪除子公司；我們可以把這些權限授予比如“張三”這個用戶。在授權的時候，我們可以細化到這種程度：

1.明確規定：允許張三查詢公司信息、更新公司信息 2.明確規定：不允許張三添加公司信息、刪除公司信息 3.至于張三是否能執行添加子公司和刪除子公司這些操作，我們可以不做明確規定，而是由其所擁有的角色，或其所屬的部門、崗位的權限來決定，這稱為“權限的繼承關系”，針對這種需求，在ACL中，我們設計了一個額外的屬性：aclTriState，用來表示某種操作的權限是否是繼承下來的。

5、我們這個設計的缺點在哪里

a)角色之間沒有考慮父子關系，如果考慮父子關系的話，會更加便于授權，比如假設有一個角色為“普通員工”，另外一個角色是“檔案管理員”，如果把普通員工看成是檔案管理員的父角色，則意味著檔案管理員這個角色的權限將可以繼承普通員工中的權限（為什么沒有實現這個設計呢，客戶認為沒有必要，因為系統中的角色數量比較少，如果這樣設計的話，反而會增加客戶操作的難度，無需過度設計）b)我們還沒有實現更細粒度的數據級的權限控制，比如，我們目前通過權限控制系統無法實現如下需求：規定張三可以查看所有部門的員工信息，但只能對本部門的員工信息執行添加、刪除和修改操作。沒有實現的原因是：客戶目前這方面的需求還不是很多，因此，沒有必要在權限控制系統中實現。實現上述需求，我們是將這些邏輯寫到了具體的代碼中，而沒有通過權限控制系統進行統一的定義。這也是大部分權限控制系統的實現策略。

工作流模塊

請描述一下你做的工作流模塊

描述思路：

1、工作流模塊的基本需求

a)請描述

2、工作流模塊的總體設計思路

a)把JBPM嵌入OA系統（如何實施的？具體過程？大概有哪些配置？）

b)表單管理、流程管理、WorkEntity、WorkApprove、EntityProperty（動態表單）

3、工作流模塊的實現技巧

a)引入jbpmeditor之后，對它做了一些定制開發（支持中文，動態表單的關聯）b)其它？

4、我們這個設計的優點在哪里

a)對JBPM的擴展 i.自定義JBPM變量解釋器 ii.可以給角色、部門、崗位分配任務，拋棄了JBPM中簡單的User-Group這種組織結構模型，使用了OA中的組織結構模型

iii.實現了自由流（如何實現的？）iv.利用自定義節點實現了會簽的決策（如何實現的？）b)動態表單設計方案

5、我們這個設計的缺點在哪里

a)在流程定義的界面上，沒有實現會簽節點的定義 b)在動態表單設計界面上，無法直接添加一些動態的組件（比如無法通過拖拽的方式添加一個人員列表等等）c)沒有實現流程的監控

第三篇：OA項目面試參考

OA系統面試說辭

面試過程中描述項目一般分為三大點（第一點是參考說辭。后兩點是可補充的說明，個人可根據具體情況介紹）

1、項目的開發背景介紹以及個人在項目中完成的功能點

2、項目的開發過程（開發周期）

3、項目的系統架構

1、項目開發背景以及個人完成的功能點介紹

我們這個項目是為XXX公司開發的一套辦公自動化系統，簡稱OA。該公司屬于XX行業，業務類型主要是XXX，該公司為了提高辦公效率與辦公質量，實現無紙化辦公與科學的管理而委托我們公司研發該系統。通過需求調研與設計，我們將該項目劃分為了XX個大的模塊。主要包括 XXX。。而本人在該項目中主要負責組織機構與權限管理兩個大模塊的設計，開發，調式以及維護等工作。

組織機構模塊主要是對該公司的部門以及人員的管理。所以在此模塊中我們又分為機構管理與人員管理兩個子模塊。由于該公司的機構屬于職能型機構，父機構下面又存在子機構，就像一個樹狀結構，所以我們在設計該模塊表的時候使用了自關聯的方式，這樣可以減少數據庫設計的允余，也便于擴展。而人員模塊設計比較簡單，就是直接在表中加入了一個機構的外鍵，因為人員肯定是屬于某個部門的。

至于權限模塊的設計就稍微復雜點。任何一個項目都會根據需求來設計相應的權限操作，權限也是我們保證項目健壯性的一種手段。在此模塊中我們分為用戶管理，權限管理，角色管理三個子模塊。因為首先我們考慮到應該為每個人員建立一個唯一的登陸賬號，我們稱為用戶，我們將權限不直接授予具體人員，而是授予相應的用戶，這樣就可以降低耦合度。但是如果具有相同權限的人都需要重復授予一樣的權限，客戶操作起來會很麻煩，而人員在公司一定有其相應的職位，所以我們決定將權限打包授予某個角色，讓角色與具體職位關聯，再將角色授予用戶，這樣就能很好的解決問題了。不過一般來說，公司有些人員可能身兼數職，也就是說一個用戶可能會被分配都多個角色，默認情況下我們是取所有權限的合集，但也會出現角色之間權限的沖突問題，因此我們在表中設計了一個優先級的字段，讓一個用戶擁有的多個角色有不同的優先級，如果權限產生了沖突，則以優先級高的角色為準。有點類似我們web程序中加載servlet時候配置的load-on-startup的屬性。當我們將項目交與客戶試運行后，客戶反映，無論什么情況都需要通過建立角色來授權感覺很麻煩，而公司的職位變動也會引起角色的增多，造成角色的泛濫。所以通過與客戶的溝通，我們修改了當初的設計，也就是除了可以通過角色來授權，也可以給用戶直接授權。這種方式與oracle數據庫的授權方式是一樣的，客戶也感覺很滿意。當然，既然可以直接授權給用戶，也可以授權給用戶所屬的角色，同樣會發生類似于開始說的兩者之間權限的沖突問題，我們解決的辦法同樣是多設計了一個字段，該字段表示是否使用用戶自身的權限還是使用其角色的權限。

我們這個項目的權限分為三級，首先在用戶登錄的時候就開始驗證是否有資格進入，（這是第一級）在通過該驗證后，我們會查詢出該用戶擁有的所有具有可讀功能的模塊并展示，對于該用戶不可讀的模塊是不會展示出來的，這樣能避免用戶的誤操作（這是第二級）。但有些模塊該用戶雖然具有可讀權限，但是沒有更新與刪除等權限，我們此系統也可以及時屏蔽該誤操作（這是第三級）。

2、項目開發周期 本項目總開發周期為1年，具體分為以下幾個階段

1、需求分析階段，由系統分析員對客戶進行需求調研，產生需求分析說明書，經客戶簽字確認。

2、概要設計，由系統分析員根據需求分析書編寫概要設計文檔，經客戶簽字確認。

3、詳細設計，由系統分析員和架構師根據概要設計文檔編寫詳細設計文檔，經客戶簽字確認。

4、用戶手冊，根據以上三個文檔編寫用戶使用手冊

5、數據庫設計，由系統分析員做數據庫架構設計，生成數據字典

6、系統架構設計，由系統架構師做整個系統的架構設計，產生架構說明文檔

7、分模塊編碼，主要由程序員進行分模塊編碼，并由測試人員對模塊進行交叉測試

8、系統集成（也叫產品集成）

9、集成測試（對整個系統的產品結構功能進行整體測試）

10、上線試運行，將集成后的產品交付給客戶進行試運行，對試運行期出現的錯誤進行修改

11、產品交付，試運行完后，如果產品沒有什么問題之后，對客戶交付產品

12、后期升級與維護(根據合同規定)

3、系統架構

本系統是基于J2EE平臺，采購B/S模式進行開發，數據庫采購oracle，系統框架采用當今主流的SSH集成。分層架構進行開發，主要分為數據層、業務層、界面層。

第四篇：江門供電局電力營銷管理信息系統項目實施經驗

龍源期刊網 http://.cn

江門供電局電力營銷管理信息系統項目實施經驗

作者：劉 鑫

來源：《科技創新導報》2011年第34期

摘要：本文通過對江門供電局電力營銷管理信息系統項目建設過程的分析，總結了項目準備、建設、驗收過程中的工作經驗，對于市供電局電力營銷管理信息系統項目建設起到一定的指導作用。

關鍵詞：電力營銷 管理信息 系統建設

中圖分類號: TM76 文獻標識碼：A 文章編號：1674-098X(2011)12(a)-0000-001 江門供電局電力營銷管理信息系統情況

1.1 原電力營銷管理信息系統概況

江門供電局電力營銷管理信息系統是覆蓋江門地區，包括三個區、四個縣（市）的近兩百萬電力客戶業務。原使用系統采用數據分散管理的方式，數據存放在各個縣區供電局，采用基于J2EE和SOA體系構架的純b/A/S二層體系結構。各縣區局的分散管理，不利于大部制改革中全市營銷管理模式的統一；也不利于數據安全；也極大的浪費了管理方面的人力、物力資源。

1.2 原電力營銷管理信息系統數據架構及特點

原用電營銷系統數據庫總體框架結構如圖1.1所示，主要包含業擴中間庫檔案、業擴傳票信息、用戶檔案、計費檔案、電量電費明細及帳務信息、計量信息、用檢信息、供用電合同信息、用電營銷主體數據和電量電費歷史信息等內容。

整個用電營銷系統數據結構設計有如下特點：

（1）業擴中間庫檔案和計費檔案完全分離；

（2）用檢檔案獨立于用戶檔案，減少空間開銷；

（3）歷史數據和近期數據分離，保證日常數據處理的性能不隨時間增長而顯著降低；

（4）每月形成穩定的主題數據，一方面可以保存每月報表，另一個方面可以實現快速的數據分析。

圖1.1用電營銷數據庫總體框架結構

1.3 新電力營銷管理信息系統的優化

新的電力營銷管理信息系統相較舊系統而言，最主要的優化體現在對各業務模塊的整合上。江門供電局電力營銷管理信息系統通過運用信息技術，采用計算機網絡等現代化管理工具，建立一個多功能的綜合電力營銷管理信息系統。實現信息資源共享，規范用電管理、輔助領導決策等功能，從而顯著提高企業的管理效能和經濟效益，如圖1.2所示。

圖1.2電力營銷管理信息系統模塊關系圖項目實施

2.1 項目實施的準備工作

2.1.1 建立完善的組織和制度保障體系

按照管理上的“同素異構原理”和“能級層序原理”，在項目籌備之初，確定項目實施組織結構，并明確了職責分工和協作規范。具體分組主要為：上線運行領導小組；運行工作小組；開發方住縣區局定點實施人員；業務功能負責范圍。

其中，業務功能負責范圍按營銷管理氛圍：計量、用電檢查；抄核收；業擴管理；系統管理及聯絡人員設置四個部分。

工作小組的工作內容主要分為三級：

（1）核心層：負責小組工作例會及營銷系統運行過程發生緊急事情的會議召集，負責日常工作的分工、協調。

（2）管理層：負責每日營銷系統運行問題的收集、整理、分類匯總，并按照業務范圍責任到人解決，對于管理層小組不能解決的問題經過核心層審核后提交東方電子公司住開平實施人員，由實施人員解決或協調江門開發小組一同解決。并負責將處理結果及時反饋各所。

（3）操作層：負責日常操作過程中（計量、業擴報裝、抄核收）相關業務流程的各項問題收集，并每日提交管理層。

2.1.2 擬定具體工作計劃，建立投運倒計時時間表

按照投入運行的計劃，在最后一個月建立投運時間表：

（1）倒數30天進行第一次數據轉換；

（2）倒數28天開展推廣局的業務培訓；

（3）倒數25天進行第二次數據轉換，在此過程主要發布兩個系統應用。一個作為推廣局系統試運行試用，一個用來做基本檔案數據的完善和比對，作為各推廣局正式上線的數據庫，基本檔案數據不再轉換；

（4）倒數20天進入雙軌運行，同時進行新舊系統電費數據的比對和完善；

（5）倒數15天對舊系統進行工作單歸檔，當月發生變更的數據由開發方轉入到新系統。倒數14天各基層單位在新系統進行工作單受理，舊系統收費；

（6）倒數10天在新系統抄表；

（7）倒數8天在某一時點（如16:00）舊系統停止收費；

（8）倒數5天組織進行上線前票據流程檢查及發票的試打印；

（9）倒數4天開發方對歷史電費（三年）、欠費檔案、實收檔案、余額檔案、核銷檔案、臨時接電費檔案進行轉換，各縣區局組織核算人員進行新舊系統欠費數據比對；

（10）正式上線。

2.2 項目實施過程控制

2.2.1 硬件準備

保障全區營銷系統網絡暢通，確保各個基層單位能順利接入新系統開展試運行工作，要求營銷系統使用人員的客戶端必須能夠通過IE瀏覽器訪問市局營銷系統。

完成基層運用單位的硬件設施配置工作，搭建終端電腦設備，設置好相關的配套設備（如抄表機、高速打印機等）。

營銷系統基于微軟IE瀏覽器進行操作，要求每個客戶端必須具備系統所需客戶端硬件、軟件配置。

2.2.2 人員權限設置

在雙軌運行前，完成營銷系統應用人員的權限配置和系統的基本設置工作。由縣區局在雙軌運行前確認本單位工作人員的權限清單，系統開發方根據清單在3日內完成人員權限的設置以及各單位系統的基本設置工作。

2.2.3 分期、分批次培訓

首次培訓的人員主要對象為：能熟悉使用鍵盤、鼠標，熟練地錄入和編輯中文文字；熟悉Windows操作，操作系統使用，了解文件結構，熟悉文件管理、執行命令等基本操作；熟悉瀏覽器（如IE）的日常使用和配置；熟悉業務流程管理規定，對所負責的業務精通的人員。其次，參加培訓人員按照專業組織進行一次集中培訓，培訓后經過考核合格方可上崗，培訓需達到每個基層單位、每個業務均有一人通過考試。

最后，通過遠程教育培訓網絡對其他人員進行視頻授課，并由集中授課通過考核的人員組織個性化的基層培訓。

2.3 項目實施的反饋控制

在新系統正式啟用之后，由工作小組的操作層人員對日常運行過程中出現的問題進行收集、過濾后由管理層審核，確認有必要增加的功能提交市局審核，市局經審核并同開發方、監理溝通后確實有需要開發的的功能則提交開發方開發，沒有必要開發則反饋基層。3 項目實施的關鍵經驗總結

3.1 投運時間表采用表單式運作

投運時間表采用表單式制作，主要涉及內容有：項目、工作內容、負責部門、起始時間等，通過表單式運作明確了工作內容、負責部門、時間安排等重要信息，對于投運計劃的按時完成起到了化整為零的作用。

3.2 新功能需求開發的閉環管理模式

在新功能需求開發的工程中采用閉環管理的模式，主要流程可以概括為：

（1）需求提出：由局方工作小組收集整理基層需求，結合日常工作提出對新系統開發的需求；

（2）功能審核：對局方工作小組提出的需求，由工作小組、開發方和監理方對需求進行審核，確認需要開發的功能。對基層提出的經討論不開發的功能，經確認后由工作小組反饋到基層。

（3）功能確認：經開發方開發的功能，提交局方工作小組測試，經測試合格后發布使用。測試不合格的功能列明不滿足使用條件的原因，再次提交開發方調整，如此循環操作直到測試合格。

3.3 以點帶面的上線模式

江門供電局共有三區、四縣需啟用電力營銷管理信息系統，為做好上線的準備工作，選取蓬江工作局做為試點，為全市推廣電力營銷管理信息系統積累運行經驗，并在運行中有針對性的對發現的問題進行解決。

選取蓬江供電局作為試點，主要是考慮蓬江供電局作為市區的城區局，客戶數量相對適中、客戶檔案比較復雜、地理優勢明顯。這些都成為蓬江供電局作為試點縣區局的特出優點，通過整個過程來看，也確實達到了作為試點的目的。

3.4 日常問題頭腦風暴解決模式

為加強系統實施工作的領導和管理，解決日常出現的問題，在每個縣區局設立對應于市局工作小組的模式，設立每日工作小組聯絡會議制度，由工作小組組長主持，采取頭腦風暴法重點討論發現問題，尋找解決辦法，對于不能解決的問題，次日提交市局營銷系統工作小組。具體討論的問題由基層操作人員負責收集所在單位的問題，每日反饋至運行工作小組，由小組聯絡員匯總分類，分發專業小組負責人解決。各組不能解決問題，提交開發方駐點實施人員，由實施人員協調開發方解決問題。結語

本文集中對江門供電局電力營銷管理信息系統項目實施做了描述，并通過對其過程分析，解讀了實施過程中的經驗，對于電力營銷管理信息系統的數據架構、模塊管理、開發應用起到了一定參考作用。

參考文獻

[1] 張德 《人力資源開發與管理》 清華大學出版社,1996.[2] 顧旭 《企業戰略與投資決策》 上海財經大學出版社，2005.

第五篇：項目經驗

我的項目經驗：項目日期：2010年6月-2010年8月

項目名稱：臺泥公司儲運碼頭儲料系統改造

擔任職位：電氣工程師/技術員

項目描述：1.目的：為提高倉重計量的準確性及減少現場對稱重信號的干擾而進行的技術改造，從而實現中空室監控的數據與現場儀表反饋回 來的料位，重量信號數據的一致。通過重量或者料位來控制電機的啟停。

2.介紹：本項目的控制部分由稱重傳感器，現場重量顯示儀表，s7-200 CPU226的PLC，EM277擴展模塊，擴展DI/DO，上位機監控，氣缸組成。它的工作原理是當現場把控制柜的按鈕打到手動則進進入手動調試狀態，手動調試包括倉重的校驗，電機和做閥門的測試等。倉重的校驗是當按下氣缸啟動按鈕氣缸動作將校驗砝碼掛上倉體，然后根據儀表顯示的重量與砝碼的重量的對比進而調節偏差。上位機監控的重量數據是從現場儀表發送過來的。因此校驗好現場的倉體重量就可以投入使用了。當把控制柜的按鈕打到自動時中空操作員可以對現場設備的啟停操作。如果遇到緊急事故，整個系統會進入停止運行狀態。

責任描述：這個小型的系統由三部分的人員完成。第一部分是由公司的工程部完成，他們的任務是負責對現場硬件設備的改裝，負責現場的施工工作；第二部分和第三部分是我們電氣人員負責，而我主要負責的是PLC的程序設計和改進。其他的技術人員則做人機界面的畫面組態和改進。經過2個月的對項目的改造我完成了PLC主體程序的改造設計，還有比較復雜的通信部分由領導完成。

經過這2個月的學習和對項目的改造我的編程技術又上了一個臺階，對整個自動化控制系統有了更加深入的了解，總之受益匪淺。