信息系统管理制度

文件编号：

编写部门： 行政人事部

编写人：

审批人：

审批日期：

第一章 产品目标与管理模式

本章节旨在解决产品链的建立、衔接与管理，明确纵向产品体系和项目经理管理模式。

1.管理模式

1.1管理方法

产品化管理，在原直线职能管理模式基础上实行矩阵式管理，由项目经理对项目组所开发的产品负主要责任，从需求——开发——测试——发布——培训——实施的整体业务体系全程监督与控制。

1.2管理重点

抓“两头”放“中间”。其中，抓“两头”是指项目经理主抓业务需求和总体框架、抓数据库结构；放“中间”是指部门范围内开发代码，实现模板化编译和信息资源共享。基于场所层面的开发重在解决管理职能，基于地市省厅层面的开发重在解决指导职能。

1.3管理源头

需求是软件开发的根基、是节约成本的源头，需求描述必须可交流、格式化，经开发、测试和培训服务三方共同理解与确认的需求说明文档，是信息系统流程运作的主要依据。

2.产品目标

2.1产品体系

以看守所系统为主导产品，带动治安拘留所系统、安康医院系统、收容教育所系统等场所产品发展，着手研制强制戒毒所系统。在实现基本业务功能和充分数据采集的基础上，将一系列产品挂至省厅地市系统，实现综合应用和深挖犯罪。

2.2开发模式

·开发结构：场所开发C/S结构为主，B/S开发旨在充分利用网络资源实现信息的充分共享和综合运用。B/S与C/S结构开发相互独立、留有接口。

·开发方法：由原型法转入瀑布法，加强需求调研与开发质量，为后期维护减负。

·开发方向：产品模块化和智能化运作，明确系统主体业务模块与非主体业务模块，在主体业务功能完善的基础上稳定产品；在充分实现系统数据采集的基础上，实现WEB平台的综合应用和深层次的犯罪挖掘。

3.发展目标

·第一阶段：采集数据。与硬件系统集成，实现采集系统的功能拓展。

·第二阶段：综合应用。通过业务报表实现查询功能，通过数据接口对外部系统形成连接平台，引导行业标准。

·第三阶段：数据挖掘、横向联查，形成一个庞大的数据挖掘系统。

·第四阶段：将数据应用系统作成公安系统的办公平台，成为公安系统日常工作不可或缺的办公工具。通过平台反向促进数据采集的准确率。

4.市场定位

4.1竞争对手

目前有湖北东方（业务导向）、华迪公司（BS优势）、深圳胡晓峰（OA理念）、南京科安（份额优势）、上海三所等。需时时了解对手动态，掌握对手优势，做到知己知彼、对症下药。

4.2竞争策略

看守所层面形成绝对市场优势和技术优势，其它系统才能进入市场，形成绝对垄断。信息系统市场的巩固与拓展，是带动系统集成业务发展和获取收益增长的前提。

4.3.市场定位

稳固看守所系统，挖掘省厅地市、拘留所、强制戒毒所等信息系统，争取部局系统，逐步向地铁公安、公安消防等相关行业信息系统递延。

5.工作重心

·明确信息系统主体业务，确立与主体业务相关的需求和功能模块，以及非主体业务应用等级。将主体业务分离，结合非主体业务的应用等级分阶段对系统进行完善和稳定。原则上主体业务部分只保留一个标准版本，非主体业务视情况分离出相近地区版本。

·综合应用组B/S结构开发从设计阶段开始就明确功能结构和开发目标，确立信息集中和综合利用的观点，充分考虑数据利用模式和业务应用模式。加强市局模块功能的补充和完善，开发团队并入综合应用项目组。

·场所项目组中，看守所系统实行模块化分割，以维护为主；拘留所系统实行“两条腿走路”，边维护边更新；安康医院系统和收容教育所系统重构框架；新开发强制戒毒所系统。

·测试部统一管理信息系统产品版本库，负责版本确定、编号以及出入库管理。

·定时收集各地用户需求，并尽量收集竞争对手的应用状况和资料，作为C/S系统的修改参考和B/S结构的设计指导。

·确立周五信息系统工作例会制度，例会前各项目经理提交项目计划与工作安排给部门负责人、公司主管领导，并抄送行政备案。

·根据产品目标与工作重点层层分解、责任到人。项目进度安排及完成情况使用MS Project，缺陷管理工具使用IBM Rational ClearQuest。

·以项目计划和资源状态报告作为业绩考核的书面依据，以需求分析报告和测试报告作为流程考核的书面依据。

·建立良好的沟通机制，项目组之间信息共享、相互学习，同时形成良性竞争机制。

第二章 团队规模与建设

本章节旨在解决团队组织架构、知识架构、人员编制、岗位职责、职业规划、培训方向。

1.组织架构

1.1直线职能机构

1.2业务矩阵结构

注：信息工程部项目经理对所负责的产品负主要责任，从需求——开发——测试——发布——培训——实施的整体业务体系全程监督与控制。

2.知识架构

2.1.专业人才配置需求

2.2.专业经验配置需求

2.3.学历层次配置需求

2.4.综合素质配置需求

3.定编定岗

3.1.职位编制

3.1.1总经理助理（编制人数1人）

3.1.2信息工程部（编制人数共计18人）

3.1.3测试部（编制人数5人）

3.1.4培训服务部（编制人数6人）

3.2部门职责

3.2.1信息工程部

·编制部门技术发展规划、技术管理制度，遵守信息系统业务流程；

·设计产品方案、实行新品开发、遵守技术规范，控制产品质量；

·组织需求调研、系统设计与代码编写，对项目进行阶段性评审及审批，保证项目进度与质量，组织产品认证和内部单元测试与功能测试；

·及时编制开发文档，认真作好资料归档，严格保密与交接制度；

·及时处理和解决产品出现的技术问题，确保经营工作正常进行；

·召开技术研讨会议，组织部门人员为其他部门提供技术支持；

·服从公司领导工作安排。

3.2.2培训服务部

·建立健全业务及产品培训大纲，编写用户手册；对产品进行演示、安装、培训；

·现场处理用户问题，后期技术支持与电话跟进，及时收集、反馈准确用户需求；

·策划宣传材料、公司网站，维护公司形象工程，与用户建立良好合作伙伴关系；

·会同财务部门作好应收帐款的催收工作；

·配合开发、测试部门执行信息系统业务流程与工作制度，相互协调配合；

·服从公司领导工作安排。

3.2.3测试部

·制订测试计划，保证测试质量，验证测试结果，实施测试评估，参与技术研讨；

·分析软件错误类型，为开发人员修改错误提供参考意见；

·建立产品版本库，掌控版本变更情况，发布版本确认或变更说明；

·配合开发、测试部门执行信息系统业务流程与工作制度，相互协调配合；

·管理公司技术文档、资料和图书，及时提供信息查询。

·负责ISO9000的监督、内审及管理评审等工作。

·完成领导交办的其它工作。

3.3管理层岗位职责

3.3.1总经理助理（分管信息系统）

·全权负责公司信息系统（包含信息工程部、培训服务部、测试部）主营业务工作。

·查阅财务报表和经营资料，掌握信息系统整体业务情况，及时提出经营调整策略。

·拟订公司信息系统业务发展规划、经营目标，确定技术发展方向，承担经营责任。

·主持召开信息系统内部经营例会与技术研讨会议，掌握、控制经营、技术活动。

·主持信息系统日常经营管理工作，签署日常行政、业务文件，调配人力资源，组织绩效考评，建设技术队伍。

·对公司信息系统质量体系建立、实施、完善和决策负责，为开展与质量有关的活动提供充分的资源。

·会同行政人事部组织编写并审核信息系统内部机构调整方案和管理规章、业务流程和岗位职责，保证公司标准化、程序化、制度化管理的实施与监督。

·完成上级领导交办的临时工作任务。

3.3.2信息工程部经理

·对产品技术方向、市场定位、技术方案、工作流程等组织评审和认定；

·对项目整体需求把握、框架设计和数据库结构组织评审，监督业务运作流程；

·审查项目计划及完成情况，组织技术把关和指导，及时组织处理质量事故；

·负责对各项目组产品认证和内部可操作性测试与代码审核情况进行抽查；

·审核技术文档的完整性，编制测评标准、技术规范与质量认定标准并监督执行；

·负责技术队伍的建设、管理，提出工作岗位配制要求及调配建议；

·召开技术研讨会议，组织部门人员为其他部门提供技术支持；

·监督考核各项目组工作，强化开发队伍建设与培训，收集归纳合理化建议，为公司领导提供决策支持，完成公司领导临时交办的各项任务。

·通过任务管理工具Project来了解各个项目组的任务进度及审阅项目状态报告；

·通过ClearQuest了解并监督各项目组的产品质量情况，并执行相应的奖罚措施；

·通过代码管理工具VSS或CVS对各项目组的代码的规范及质量进行抽查、监督，并执行相应的奖罚措施；

·组织部门内部的技术交流及培训，提高部门员工的素质；

·协调各项目组之间的关系，及处理好与其他部门之间的关系；

·对部门外部及客户的需求及时作出反应，安排相关人员进行处理。

3.3.3项目经理

·需求理解与把握。在需求调研阶段，深入到客户的实际工作岗位上，仔细观察与询问，通过电话方式或Email方式进行事后跟踪；对反馈的需求进行确认与研究可行性，确保需求准确，与培训服务的同事了解他们与用户的一些想法，和合理化建议。和培训服务的同事商量方案的可行性。

·系统设计、概要设计、框架搭建、数据库结构；

·制订开发规范，如代码规范、注释规范、变量命名等；

·通过任务管理工具PROJECT合理地作任务安排（根据每个人的实际情况来进行安排，作到各尽其能），并每日审查任务完成情况，

·审查代码编写质量，组织成员绩效考评；

·通过Project每周向部门经理提交项目状态报告；

·安排组员交叉测试，组织单元测试抽查，递交测试版本；

·安排组员编写详细的需求与测试报告，对每个模块的测试重点进行说明。与测试部同事沟通，及时知道测试结果，组织相应的修改。

·把好出口关，打包封装软件，实行配置管理；

·产品运作流程与质量的监督与控制；

·通过源代码管理工具(VSS或CVS)对本项目组的源代码进行管理；

·通过ClearQuest,对项目组成员进行缺陷管理；

·产品运作流程与质量的监督与控制；

·不定期组织项目组内的技术、业务讨论会，对项目组成员进行业务及技术的指导；

·协调与其他项目组或其他部门的关系，为其提供技术支持；

·对部门经理负责，及时汇报工作与项目进展情况，申请资源之类问题。

3.3.4.测试部经理

·审核规范公司技术文档，制订规范通用的测试标准，作为软件测评质量的考评标准；与信息工程部、培训服务部经理共同确定需求，作为测试通过的衡量依据。

·审核测试计划，掌握测试进度，实施质量评估，验证测试结果，参与技术研讨。

·分析软件BUG类型，运用测评工具分析统计，为软件开发质量考评提供依据。

·掌控版本变更情况，发布版本确认报告、评估报告和变更说明。

·负责ISO9000的监督、内审及管理评审等工作，严格监督质量体系运行情况。

·强化测试队伍建设和部门绩效考评，收集提炼合理化建议。

·完成公司领导临时交办的任务。

3.3.5.培训服务部经理

·根据用户需求部署产品培训与技术服务，检查工作效率，实时收集与反馈用户信息与竞争对手资料，做出市场分析，与信息工程部、测试部经理共同确认需求；

·审核公司业务及产品培训教材、用户操作手册，组织编写宣传材料、更新网站；维护公司形象工程，与用户建立良好的合作伙伴关系；

·参与公司主要经济问题的分析，会同财务部门作好应收款项的催收工作；

·强化培训服务队伍建设，组织业务及技能培训，及时处理用户反映的技术问题；

·收集合理化建议，作好公司领导的参谋，完成公司领导交办临时工作任务。

4.人员分析与职业规划

5.人员调整

5.1职务晋升或平级调整

5.2.职务降级与末位淘汰

6.人员招聘

详见《公司行政人事制度》。

7.业务培训

7.1培训内容

7.2培训方式

内培为主，外培为辅。内部培训安排专题培训与讲座，鼓励员工自行担任主讲，实现资源共享，并按50元/次奖励主讲人员，外部培训以资质认证为主，按《公司行政人事制度》和《培训合同》相关条款执行。

7.3培训时间

公司内部开辟《培训园地》，每两周一次，周五下午4：00至5：30。也可由各部门自行提请。

第三章 工作流程与沟通

本章节旨在解决需求源头、版本控制、责任环节、业务衔接、文档管理等问题，切实推行以项目经理为导向的产品生产和业务运作流程。

1.业务工作流程

1.1版本发布流程

流程说明：

·根据市场需要，由培训服务部提交《版本申请书》（注明需要时间、部署地点、系统配置需求、对产品的特殊要求等），如无明确地方需求，由测试部从产品版本库中提取标准版本；如产品版本库中现有产品不符合要求，由测试部转发《版本申请书》给信息工程部相应的项目经理进行确认和修改，修改完成的版本经测试部评估并确认合格后，作为产品发布版本记入产品版本库。

·测试部根据培训服务部《版本申请书》中的系统配置要求（指支持系统运行的所有服务器、客户机及网络设备、通讯链路以及存储设备、输入输出设备机器型号及配置和其他设备规格要求等的硬件配置说明；以及所使用的系统软件、平台软件、开发工具软件等的说明），对拟发布的版本进行系统配置，并刻出母盘，提交培训服务部作为产品发布的样品。

·因产品完善和功能扩展需提交测试的，必须事先由信息工程部项目经理制定详细的开发计划并抄送测试、培训服务部经理，修改后经过测试确认的版本按时间标注小号，记入公司产品版本库。

·在版本要求时间与实际提供时间存在差异的，由各部门经理协商解决。

1.2版本控制流程

流程说明：

·由培训服务部提交用户反馈，经测试部初步审核，对描述不清或是有歧义的描述退回培训服务部重新整理提交。

·测试部将需求信息转交信息工程部项目组，由项目经理过滤后，提交信息工程部、测试部、培训服务部会议讨论。经三方签字认可的《需求确认报告》方可作为开发凭证和测评依据。

·三方认可的《需求确认报告》与用户实际需求不一致的，由培训服务部形成《需求处理报告》，与用户沟通需求差异，合理引导和说服用户。

·项目经理提交测试版本的依据是系统开发和完善计划，来源主要有三：根据用户反馈对现有版本的完善；根据市场要求确立的新产品开发；根据实际需要由信息工程部主管制定的开发计划。系统开发计划需由相关负责人用Project制定并发布至Project Server,提交测试版本时必须附上相应的版本说明。

·测试人员对系统进行测试时，可根据具体情况决定版本是否能够发布，对不符合要求的版本退回给项目经理进行修改，版本号不升级，三次以上提交仍不合格的，升级版本号并记入不合格版本库，退回给项目经理重新制定修改计划。测试确认可以发布的版本附交《版本说明书》，并对每次版本的升级提交测试报告和评估。

·产品版本库的编号规范包括以下内容：

—产品类型代码（如KSS）

—版本类型代码（标准版本为公司名称缩写BS；地区版本用两个拼音字母表示，如ZJ）

—合格代码（合格为1，不合格为0）

—升级代码（如NO.1）。

举个例子:“KSS-ZJ-1-NO.2”代表“看守所系统浙江合格版本第2次升级版本”。

1.3异常处理流程

流程说明：

·除了试点之外，公司产品在部署完成后，需整体更新的，要遵循异常处理流程。

·各部门均可提交异常处理请求，需注明处理原因，因产品质量问题引起的异常处理由信息工程部部门经理负责处理，向公司提交异常处理请求。获得同意后即可按异常处理流程运作。

·异常处理完成后由培训服务部门提交反馈信息，由各部门经理对处理作总结。

2.责任分布

注：主要责任为▲，次要责任为△。

3.文档管理

说明：

·文档模版详见附件；

·流程文档，指实现业务流程必须全程跟进的文档，非流程文档只需部门自行留存。

·信息工程部项目组备存的文档由项目经理管理，测试部备存的文档由美工兼文档员管理。

4.沟通机制

4.1.内部沟通

·项目经理对部门经理负责，让部门经理随时了解项目进度、质量和所需资源；

·项目组之间信息交互，就技术难题开展技术研讨，寻求技术支持与业务指导；

·项目组内部实时沟通交流。

4.2.外部沟通

·对培训服务部拿回的需求，项目组要实行可行性论证，分析技术上是否可实现。

·调研或出差时深入用户工作岗位，获取第一手资料，回公司时索要对方电话并保持联系；对开发、测试、培训服务三方共同确认的需求，必须与用户及时沟通、达成一致。

·项目组在提交测试时附上说明文档，指明版本实现目的以及关键业务和难点。对测试情况要及时询问，避免完全测试完成再行修改。

·信息系统各部门在考勤考核、人事安排、监督奖罚等方面要取得行政人事部门的支持。

4.3.沟通工具

4.3.1．每个项目组通过Project来安排工作,提交工作进度。

·项目经理通过projectg来安排任务给组成员，做到项目组成员每天有明确任务分配,便于对组成员的日常考评及月考评,应避免在项目在某时期没有工作记录。

·项目组成员应认真填写project的工作记录及进展情况，做到每日提交，这做为日常考评及月考评的重要依据。

·项目经理每日审核组成员的工作进度及质量问题，根据项目进展情况进行适当调整。不要项目提交到project上后一成不变，失去了它的应用意义。

4.3.2．项目经理通过project项目状态报告，来向上一级提交工作情况及计划。

·项目状态报告每周五提交部门经理、总经理助理以及行政人事部。项目状态报告应填写如下内容：本周的工作情况（详细记录项目组工作进展，用户反馈及处理情况（用户的单位、反馈的问题）、出差人员的反馈情况记录、下周的工作安排、本周的热点问题、本周未解决问题。

·项目状态报告是项目经理提交上级部门的重要文档及工作进展情况的重要依据之一，作为月考评的一项存在。

4.3.3．缺陷管理使用Clear Quest工具。该工具是测试部与开发部门交互使用的。

·项目提交测试，测试部部门把某项目按照Project上的项目安排建立该项目的数据库，把功能模块和提交人对应。

·项目组成员用Clear Quest客户端查看自己完成模块的测试情况，并提交自己的修改方案。

具体使用由信息工程部统一培训。

第四章 强化监督与考核

本章节旨在通过版本业务流程的考核和人员日常工作业绩的考核，监督流程运作质量，将责任心的核查与奖惩具体兑现到日常工作中。

1.监督

1.1.工作计划

即阶段性工作目标和时间表，包括项目计划、年度计划、月度计划和周计划。工作计划及时间表必须按时递交部门经理及公司主管领导，同时报送行政人事部备案。设置PROJECT用户权限，掌握项目进度与完成质量。

信息系统业务部门内部建立周例会制度，及时检查效率、总结经验和部署工作。

1.2.监督重点

项目经理对项目组分配产品从需求——开发——测试——发布——培训——实施的整体业务体系全程监督与控制。监督采取抓“两头”放“中间”。其中，抓“两头”是指项目经理主抓业务需求和总体框架、主抓数据库结构；放“中间”是指部门范围内开放代码，实现模板化编译和信息资源共享，代码编写质量采取抽查的方式予以评估。

1.3.抽查方法

三种方法同时进行：项目经理自查、公司主管领导抽查、公司主管领导委托项目经理交叉检查。抽查的前提条件是项目组之间在整体框架设计上思路统一。抽查的内容主要是检查软件代码编写的规范性。

2.考核

2.1.业务流程考核

以需求确认报告核定的版本发布周期为考核周期，由总经理助理面向项目组的产品运作流程全面考核。考核结果作为部门经理、项目经理任职资格的评定依据，也作为项目经理对下属员工奖惩兑现的依据。

业务考核分数=∑（进度考核分数+质量考核分数+需求考核分数）/3

2.1.1.进度考核指标及标准

采用任务延期率进行考核，需求确认报告核定的版本发布周期为计划执行天数，如需变更计划执行天数需以变更后的需求确认报告为准，甲方认可的计划延期也可视同为计划执行天数。公式计算如下：

延期率X1=（实际执行天数-计划执行天数）/计划执行天数

2.1.2.质量考核指标与标准

由信息工程部配合测试部制订一套规范通用的测试标准，作为衡量版本质量的依据。

2.1.2.1.否决指标

主体业务模块错误率X2＞0‰，测试不通过；

系统级运行错误率X3＞0‰，测试不通过。

2.1.2.2.其它考核指标

采用测试通过率、遗留问题率、界面不统一数量等指标进行考核，以最后一次测试通过作过衡量依据。具体公式及考核标准如下，三项考核指标中任一项不达标套入相应分数：

测试通过率X4=测试用例通过数量÷测试用例总量

遗留问题率X5=遗留问题数量÷测试用例数量

界面不统一数量X6=窗体风格或按纽设计不一致的数量

2.1.3.需求满足的考核指标与标准

根据版本发布后的维护次数（系统升级不视同维护）来考核，具体考核标准如下：

2.2人员业绩考评

实行月度考核、半年谈话并确定考评等级的制度。时间在每月的25日至30日。考核由直接上级评定。即一般员工由项目经理考核，项目经理由部门经理考核，部门经理由总经理助理考核。考评结果直接影响到薪资调整与人事调整。

2.2.1月度考评

2.2.1.1信息工程部

2.2.1.2培训服务部

2.2.1.3测试部

2.2.2半年绩效面谈

被评估人姓名： 评估人姓名： 评估时间： 年 月 日

2.2.3半年考评等级评定

3.奖惩

3.1问题处理

3.1.1项目组内部讨论解决

·经测试不通过（与需求确认报告有出入），退回修改的；

·业务考评中进度、质量、需求考核指标中任一项考核分数不足0.8的；

·因沟通不畅导致工期延误（与项目计划工期不符）的;

·经用户反馈，已发布版本存在需求理解偏差，需要修改维护的。

3.1.2信息系统内部讨论解决

·违反工作流程，忽视责任环节，影响产品发布进度和质量的；

·业务考评中进度、质量、需求考核指标中任一项考核分数为0；

·经用户反馈，已发布版本存在系统级错误或核心模块功能性错误的；

·需要调整系统框架、数据库结构，或作系统升级的；

·测试标准、程序员手册、技术规范、文档模板等的制订与修改。

3.2奖惩兑现

3.2.1业务流程考核兑现

·业务流程考评系数连续两次低于0.6，或半年内累计超过三次低于0.6，由总经理助理根据责任轻重提出项目经理的撤职、降职处罚建议。

·业务流程考评系数低于0.6，每次扣项目经理当月薪资500元，扣项目组成员当月薪资100元/人；系数高于1.0，每次在项目经理及项目组成员当月薪资基础上核发100元/人奖励。

·业务考评系数的年平均值，直接作为部门经理（副经理）及总经理助理个人考核系数，影响到留存绩效工资兑现。

3.2.2人员业绩考评兑现

3.2.2.1月度考评

·月度考评一项为“待提高”扣50元，以此类推；五项指标均达标，在个人当月薪资基础上核发100元奖励，与当月薪资合并计税。

3.2.2.2半年绩效考评

·部门内根据考评结果，排出优劣顺序,划分考评等级，考核结果报行政纳入个人档案库；

·考评等级为优秀的人员，经公司综合平衡，给予职务晋升或薪资晋级的奖励机会；

·考核等级为待提高的人员，经公司综合平衡，给予职务降低或薪资下浮的处分；

·考核等级为一般的人员，由各部门自行安排培训指导或向公司提交培训申请。

3.2.3合理化建议及创新奖

·经员工提交详细的书面合理化建议书或技术创新建议书，总经理助理认同并采纳，总经理批复，每次奖励员工个人200~500元。