电力OA项目经验

第一篇：电力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个月的学习和对项目的改造我的编程技术又上了一个台阶，对整个自动化控制系统有了更加深入的了解，总之受益匪浅。