IT部工作流程Word格式.docx

IT部工作流程Word格式.docx

《IT部工作流程Word格式.docx》由会员分享，可在线阅读，更多相关《IT部工作流程Word格式.docx（38页珍藏版）》请在冰豆网上搜索。

1.机房故障处理时间。

2.机房专用设施故障短时间无法恢复，导致机构系统不可用。

故障判断

判断是否设备故障

针对机房设备进行标示，对设备运行状态了解。

经总公司机房管理人员确认故障原因

总公司

对上报故障进行分析

故障查找、定位

会同分公司IT确定故障原因

原因分析

故障原因基本定位

根据设备保修情况，联系当地供应商维修。

供应商维修故障设备

跟踪故障处理

记录故障处理过程，并记录备案

故障恢复确认

确认设备是否正常运转

设备供应商提供设备故障检查和正常运行报告

故障恢复

核实故障处理结果

4、流程信息清单

六、计算机桌面管理流程

1、总、分公司部门权限、职责情况

分公司IT岗

严格按照总公司IT部下发的桌面管理制度实施日常维护；

在日常维护中，发现解决不了的问题，及时反馈到总公司IT部；

在日常维护中，对IT维护工作效率有显著提高的实践，可上报总公司，以便在各分公司推广。

总公司IT部

收集分公司在日常工作中遇到的桌面相关问题。

整理、分类分公司提交的问题，及时反馈、解决问题。

撰写、下发桌面管理制度及相关制度。

根据IT技术地不断发展、不定期撰写新制度、修改旧制度等。

不定期督促、抽查分公司桌面管理制度的落实情况，并适当地给予相应的奖励、惩罚。

公司其他部门员工

严格按照总公司IT部下发的桌面管理制度实施日常维护。

不允许擅自重装操作系统及各种软件。

在日常工作中遇到计算机异常情况，及时可以通过电话、电子邮件、飞秋等方式上报到系统管理员。

等待处理问题的响应级别优先顺序（从高到低）：

总裁室>

各部门一把手>

各部门领导班子>

各部门室主任>

各部门一般员工。

2、流程图：

1）计算机硬件故障处理流程

2）：

计算机软件故障处理流程

工作内容、流程步骤

计算机桌面管理流程

用户计算机故障出现

非IT部门

---

计算机出现故障，影响工作

上报故障，要求排除

提交故障现象描述，请求排除故障

1、根据轻重缓急和响应级别优先顺序来决定先解决哪些故障。

2、收到故障上报，及时响应。

3、收到故障上报，及时处理。

4、在故障解决需要时间较长时，可通过变通方式让用户恢复正常工作。

IT分析故障、处理故障

IT部（系统管理员）

根据故障现象分析

分析故障现象，缩小故障源的范围

定位故障源为软件或者硬件

IT分析故障、处理故障（硬件故障）

计算机硬件厂家维修商

根据IT约定的时间上门维修

（在保修期内的计算机）上门排除故障

维修或更换硬件，使得计算机正常工作

公司签约硬件维修商

（不在保修期内的计算机）上门排除故障

IT分析故障、处理故障（软件故障）

定位为操作系统故障

重装系统，并根据标准安装进行操作

让用户在新的操作系统上工作

定位为非操作系统的软件故障

Windows系统中毒、办公软件使用异常、外接设备（打印机、扫描仪等）异常

根据具体问题具体分析，排除故障

用户最后操作

非IT部门（硬件故障）

计算机维修成本过高

成本过高，不进行维修

申请计算机报废处理

申请新计算机使用

旧计算机报废，需新计算机使用工作

获取新计算机使用

非IT部门（软件、硬件故障）

故障已排除

故障已排除，解除故障请求处理

用户正常使用计算机工作

名称

相关文档

《计算机桌面标准化安装软件清单》

七、系统开发流程

1、各部门权限情况

IT部

根据《需求规格说明书》进行系统分析和设计；

根据设计进行系统编码；

系统开发完毕后进行单元测试；

完成系统测试版本的合并及编译工作，同步完成执行脚本的编写工作；

审核提交版本清单内容，无误后提交部门内部测试；

对于部门内部整理的测试反馈问题及时修改

2、流程图

1、流程说明

系统开发流程

系统设计分析

需求规格说明书

组织部门内的需求岗、开发岗和测试岗共同讨论需求，并做设计方案分析，同步完善测试范围。

系统开发计划及测试范围

系统设计分析过程中有可能发现需求中存在遗漏或不确定的地方，需要再次同需求部门确认。

系统编码

系统开发计划

按照需求设计分析结果和计划安排，按时完成系统编码和单元测试工作

系统开发源码、数据库执行脚本及版本提交清单

系统开发过程中可能会有紧急需求介入，为了保证紧急需求按时上线，部分非紧急需求可能会延期开发

系统源码、脚本审核

系统源码抽查，数据库脚本检查及版本提交清单内容检查。

审查通过后的系统开发源码、数据库执行脚本及版本提交清单

审查出现问题后，需要提交开发人员修改

整理测试版本并提交

　--

版本合并及编译，提交可执行测试版本

可执行测试版本

版本合并工作繁重，合并风险较高，为了规避风险IT部要求同步开发版本不能超过3个，紧急需求除外。

2、流程信息清单

工具

《测试用例》

《版本提交清单》

八、数据库管理流程

提出数据库需求；

需求确认及可行性分析；

需求分类；

数据库性能监控并提取相关监控数据；

故障原因分析；

组织故障分析和讨论；

提供数据库故障解决方案及相关优化建议；

方案实施

数据库管理流程

提出需求

——

根据工作需要提出相关数据库需求。

需求描述

1．用户的需求是否影响生产数据库的正常使用。

2．解决故障的及时性。

需求分析

根据用户需求描述，做出可行性分析报告，并对需求进行分类。

可性行分析报告

性能监控

1、针对故障类需求，实时监控数据库及操作系统负载情况，提取运行数据。

2、针对日常管理和维护类需求，评估其运行效率及影响范围

监控数据

1．根据监控数据库运行的相关数据，组织故障分析和讨论会，给出相关解决方案。

2．根据方案先在测试环境中实施，达到预期效果后在生产环境中实施

实施方案

九、网络管理流程

负责网络布线配线架的管理，确保配线的合理有序；

掌握用户端设备接入网络的情况，以便发现问题时可迅速定位；

实时监控整个局域网的运转，网络通信流量情况；

例检分公司，支公司网络设备运行情况

设备的配置情况及配置参数变更情况，备份各个设备的配置文件；

监控网络通信状况；

制定、发布网络基础设施使用管理办法并监督执行情况

1）网络管理流程图

2）网络资源申请流程图

网

络

发现网络故障

对网络运行情况了解

ping命令判断故障点

迅速定位问题，是否广域网线路中断。

3.网络故障处理时间。

4.硬件设施故障短时间无法恢复。

5.专线电缆中断故障短时间无法恢复

网络设备进行标示，对设备运行状态了解。

经总公司网管确认重启接入设备

初步掌握故障原因

专线故障联系运营商解决，

设备故障联系供应商。

设备供应商维修设备；

电信运营商检查线路

总公司管理人员协助解决

故障设备进行更换

对故障仍不能排除，及时上报总公司网络管理员进行处理，为了尽量能将故障快速排除，在申报故障的时候详细描述故障现象，并将处理后的解决办法收集总结

总公司网管重新配置相关设备参数

了解用户访问网络是否正常

询问用户网络使用情况

测试网络运行是否正常

测试网络运行情况

网

资

源

申

请

提出网络

申请需求

需求部门

网络需求

分析网络需求

提出网络申请需求

1.服务申请需求及时处理情况

报批

上级领导/信息化建设委员会

超过IT部权限的网络需求申请

对于超权限的需求申请进行报批

审核意见

调整需求方案

根据审核的意见调整需求方案。

根据审核意见，结合实际情况调整网络需求。

调整需求结果

网络需求开通

根据审批意见实施网络需求

实施网络需求，整理相关实施变更文档。

实施完成

远程出单点设置申请表

服务管理系统

http:

//hausm/itsm/welcome.do

十、系统维护流程

分公司用户

通过EOA上报非审批类服务请求；

通过服务管理系统、电话等方式上报故障、问题等非审批类服务请求；

确认问题处理结果

分公司管理部门用户

对于用户通过EOA上报的问题进行审批；

对于需总公司审批的问题予以上报

响应、核实系统故障、问题；

在权限范围内处理故障、问题；

将无法处理的问题转交总公司IT部

总公司管理部门

就审批类服务进行政策审批

1、非审批类服务

服务管理系统服务响应

服务管理系统任务分配

服务处理

服务结果反馈与跟踪

2、审批类服务

分析管理部门审批意见

实施系统维护操作

反馈处理结果

应用系统统维护流程

服务查询

总、分公司用户

----

查询条件

用户查询知识库寻求问题指引

解决办法

1、服务请求响应及时情况

2、服务请求及时处理情况

3、服务请求遗失与跟踪

4、系统服务类型发展趋势

服务上报

-----

问题或服务请求描述

用户上报问题

EOA系统签报或服务管理系统任务

服务响应

工作日10分钟（服务管理系统平均响应时间）

任务分类

岗位响应问题（OA,服务管理系统）

待处理服务管理系统任务或EOA系统签报

服务审批

总、分公司管理部门

EOA系统签报申请

就下级申请事项进行政策审批

EOA系统签报

分公司IT岗位

4小时

服务管理系统任务或EOA系统签报

根据请求提供IT系统维护服务

服务管理系统服务或EOA系统签报处理结果（意见）

一个工作日

服务确认

用户核实服务处理结果，对处理结果予以确认或提出异议

服务确认结果

服务总结

用户服务确认结果

对服务进行归类总结并纳入知识库进行积累

FAQ

.

服务管理系统信息项

EOA

//haeoa/eoa/todoProcessList.do

十一、项目管理流程

1、各部门权限情况

总公司业务部门

提交原始需求说明书

配合项目组确认项目参与人员，并参与整个项目流程

协助业务部门确认需求规格说明书

协助IT部完成《系统设计说明书》的编写工作

协助确认《项目验收总结报告》

协调业务部门形成项目组，召开项目启动会议并形成项目章程

确认《需求规格说明书》

根据《需求规格说明书》进行系统分析和设计

根据设计说明书进行编码，同时监控项目质量和项目进度

协调业务部门完成项目验收工作，并确认《项目验收总结报告》

项目管理流程

项目启动阶段

IT部、业务部门

原始需求说明书

由项目经理组织召开项目启动会议，确定项目组成员及职责分工、项目的原始需求，制定《项目章程》和《项目管理计划》

确认后的原始需求说明书、项目章程、项目管理计划

此时的项目管理计划还只是初步估计的，但是一旦需求规格说明书确认后，项目管理计划将会确认。

需求分析阶段

IT部、业务部门

确认的原始需求说明书

IT部协助业务部门做详细需求分析并最终形成确认后的需求规格说明书

确认后的《需求规格说明书》

系统设计阶段

依据《需求规格说明书》对系统进行分析设计，完成《系统设计说明书》的编写。

系统设计说明书

系统设计说明书可能会因为用户的需求变更受到影响，可能会影响项目管理计划安排。

开发阶段

依据系统设计说明书进行系统开发、完成单元测试和版本整理

可运行的信息系统产品

项目验收阶段

完成《操作手册》、系统上线通知签报流程审批通过。

系统上线后，进行的各项验收工作，包括业务功能验收、技术性能指标验收等。

《项目验收总结报告》

《项目章程》

《项目管理计划》

《系统设计说明书》

十二、信息安全管理流程

1、职责范围

总公司IT部、分公司信息技术室或信息维护人员为信息系统安全的责任单位和个人，主要职责是：

（一） 

贯彻执行总公司IT部的管理办法，指导、监督、协调和规范信息系统安全工作；

（二） 

拟订信息系统安全总体规划和信息系统安全管理规定，并监督执行；

（三） 

跟踪先进的信息系统安全技术，提出信息系统安全防范策略；

（四） 

参与信息系统工程建设中的安全规划，监督安全措施的执行；

（五）负责信息系统安全专用产品的选型，组织信息系统安全的评估和审批；

（六）组织本机构信息系统安全检查，分析辖内信息系统安全总体状况，提出安全分析报告和安全防范建议；

（七）组织本机构信息系统安全知识的培训和宣传工作；

专（兼）职信息系统安全管理员应履行以下职责：

负责信息系统安全管理的日常工作；

开展信息系统安全检查工作，对要害岗位人员信息系统安全工作进行指导；

开展信息系统安全知识的培训和宣传工作；

监控信息系统安全总体状况，提出安全分析报告；

（五） 

了解行业动态，为改进和完善信息系统安全管理工作，提出安全防范建议；

（六） 

及时向总公司IT部报告信息系统安全事件。

信息安全管理流程

政策制订

根据国际和国家信息系统安全的有关法律、法规及信息技术行业的安全标准，并结合公司有关商业保密的规定，制定公司的信息系统安全政策，包括信息系统访问权限设置方案、数据备份及突发事件处理政策、病毒防治等信息系统安全政策。

配置确定

根据公司计算机及网络设备的使用规定，确定各岗位计算机资源的配置和系统访问权限。

监督与提醒

对各个网络用户及计算机设备的使用过程进行监测，同时督促各个终端用户定时对关键数据进行备份。

建立安全措施

根据公司的信息系统安全政策，选择建立各项软硬件的安全措施，包括病毒防治软件、防火墙技术等，并在网络上安置必要的预警装置；

定期在公司范围内发布病毒防治的数据资料，并提供病毒库升级下载文档。

事件处理

--　

当发生安全预警时，根据警报的性质，按照突发事件的处理规程采取必要的处理措施，并在1小时内将情况汇报至IT部经理。

事件善后

根据警报的性质判断紧急级别，视情况上报公司分管领导，采取补救措施，记录事故档案并通报全公司；

属于一般警报的记录事故档案，事故处理完毕，对于事故的责任人和责任部门编制事故总结报告上报公司相关领导处理。

十三、需求管理流程

分公司需求部门

提出需求意向到总公司直属管理部门

总公司需求部门

审核分公司提出的需求意向

提出需求意向到IT部

参加需求会商

书写用户原始需求说明书

会商确认原始需求说明书和需求规格说明书

接收需求意向进行可行性分析，反馈意见

组织需求会商

根据《用户原始需求说明书》书写需求规格说明书

对于需要立项的需求，编制需求评估报告，报上一级审批

对于下级超权限的项目进行审批

需求管理流程

提出需求意向

业务发展、增加管控等需要系统支持的想法

根据业务发展要求以及外部监管要求提出系统需求意向。

需求意向

1、需求可行性风险

2、需求变更风险

3、监管风险

分公司需求意向

审核分公司需求意向。

审核结果

可行性判断

根据需求意向结合目前系统情况进行可行性初步判断。

可行性初步判断结果以及建议

需求会商

总公司需求部门、

可行的需求意向

针对可行的需求双方进行讨论，IT协助用户挖掘需求，将用户的需求意向细化。

会议纪要/沟通结果

整理原始需求

空白的原始需求说明书

根据双方的沟通结果，书写用户原始需求。

用户原始需求说明书

审核用户原始需求说明书

审核内容是否全面，描述是否准确，格式是否符合标准。

需求评估

审核通过的用户原始需求说明书

结合需求具体情况判断是否需要立项，如需立项，编制评估报告。

评估意见

需求报批

原始需求

需求评估报告

超过IT部权限的需求，上报信息化建设委员会审批。

签报/召开信息化建设委员会

立项审批

进行需求审批，给出决策意见，对于不同意立项的需求，进行结束。

对于同意立项的需求按照项目管理流程进行后续处理。

审核意见/会议决议

需求评估意见/立项审核意见

细化用户原始需求中的功能点，整理系统的性能、安全性要求，分析该需求对现有系统的影响和接口实现方式，编制《需求规格说明书》。

需求确认

双方进行需求确认。

确认后的需求规格说明书

《用户原始需求说明书》

《需求规格说明书》

十四、需求变更管理流程

提出需求变更意向到总公司直属管理部门

审核分公司提出的需求变更意向

提出需求变更意向到IT部

填写需求变更单

会商确认需求变更单和需求变更评估报告

接收需求变更意向进行可行性分析，反馈意见

对于超权限的需求变更向上一级进行报批

根据需求变更单对需求变更进行评估

更新需求规格说明书

上级部门

对于下级超权限的需求变更进行审批

需求变更管理流程

提出需求变更意向

对已确定的需求或者已有系统的功能点需要进行补充、删减、修改的想法

提出需求变更