it项目管理重要性

it项目管理重要性（精选8篇）

it项目管理重要性 篇1

论IT项目管理的重要性

在这个学期中，我们学习了IT项目管理这门课程，让我看到了IT项目管理的重要性，因此学好这门课程是非常有必要的。

项目总是存在于我们身边的，小到一件事情，大到一项工程，而我们要想做好每一件身边的“项目”，就要充分应用好IT项目管理的知识，因此学好IT项目管理是十分重要的。只有充分利用好IT项目管理的知识，才能够从根本上提高项目的工作效率，降低项目的成本，提高项目的质量，才能够将项目做到最好。IT项目管理的重要性主要体现在如下几点。

（1）能够规范项目需求。学好IT项目管理能够使项目管理者清楚如何该怎么对项目进行管理，理解项目所需要的具体需求，才能对需求做出必要的应对。规范项目需求能够使项目更加的准确，使项目的各个阶段更加协调。因此掌握IT项目管理能够很好的规范项目需求，对一个项目来说是很重要的。

（2）能够降低项目成本。随着现在各种技术应用的不断崛起，IT项目的成本也越来越高，因此项目管理对于降低项目成本就显得至关重要了。影响项目成本的因素很多，变化也很大。项目的质量、进度和范围都与成本有关，但我们在进行项目的同时又必须得保证好项目的高质量，进度快和范围合适，那么对于如何降低成本，IT项目管理的各种方法就显得很必要了。项目管理需要对成本进行估算和规划，还要对不可见成本进行分析。这些都对与成本的控制有着很重要的作用。通过项目管理中的成本管理能够有效的计算出各种成本预算，从而能够通过成本控制能够有效的降低成本。因此IT项目管理对于降低项目成本是很重要的。

（3）能够保障项目进度。项目的进度对于一个项目来说是十分重要的，进度问题是项目生命周期内造成项目冲突的主要原因。人们习惯于比较计划和实际项目完成时间，而不愿意考虑项目被批准变更后所占用的时间，项目的交付成为了项目管理者的最大挑战。项目的进度管理具有很重要的现实意义，每一个产品都有自己的生命周期，当它处于成熟期后，便会被更新的产品所淘汰。而良好的进度管理有利于按时获利以补偿已经发生的费用支出，使项目得到更好的利用。并且有时项目进度的延迟，不仅会失去开发费用，还可能导致失去费用失去市场。因此项目的进度管理具有非常关键的作用。只有保障好项目进度，才可能会让自己的项目取得应有的回报，否则会带来很严重的后果。

（4）能够保证项目质量。随着信息技术的迅速发展，人们越来越依赖与软件，同时软件质量带来的危害也越来越严重。因此人们对项目质量的要求也越来越高，也越来越重视项目质量管理。项目的质量管理能够使产品和服务质量能满足不断更新的市场与客户的质量要求。只有质量管理达标了，才能让产品达标，让顾客满意。一个好的产品质量，才能够让团队更加自行，更为成熟，才能让顾客更加满意，更加信任团队，对顾客与项目团队建立良好的关系有很重要的促进作用。因此项目质量管理通过对项目质量进行的指挥、协调和控制等活动，能够很好的保证项目质量。（5）能够应对项目风险。IT项目由于本身的独特性，项目过程中难免有很多的变数，使项目可能面临各种各样的风险。项目风险管理是对项目中潜在的风险进行预测并实行有效的控制，如果不能很好的管理项目中的风险，就可能会造成损失，因此在项目管理中必须积极开展项目风险管理，来应对可能存在的风险。IT项目管理能够对可能发生的风险进行预测，可以在最大的可能下避免风险，对已经发生的风险也能够尽力处理好，对项目来说是非常有必要的。

学好IT项目管理不仅仅能规范项目需求、降低项目成本、保障项目进度、保证项目质量、应对项目风险，还有很多别的作用，对于做好一个项目是十分重要的。好的项目管理能够事半功倍，对做好一个项目至关重要。而没有项目管理则可能会事倍功半，达不到预想的目的。这一点在IT项目管理中体现得淋漓尽致。

总之，IT项目管理对于处理一个IT项目来说是十分重要的，只有学好IT项目管理，才可能将一个IT项目做到最好。

it项目管理重要性 篇2

而豫北转向系统股份有限公司(简称豫北)在5 年的信息化工作中,逐渐对IT治理有了清晰的认识,并认为IT治理应该是贯穿在整个信息化过程中,从信息化规划、领导力、网络基础建设到软件选型、实施、售后维护、开发等方面都起到了极其重要的作用。 因此,IT治理应该尽快提到工作日程上,渗入到日常的经营管理过程中,推进信息化工作的进程。

1IT治理

IT治理的简单定义就是使参与信息化过程的各方利益最大化的制度措施,最早是IBM将此理念引入中国。

IT治理的关键涉及以下几个方面:IT组织、IT战略、IT架构、IT基础设施、业务需求、IT投资、信息安全等。

对于IT治理来说, 目前国际上已有许多成熟的方法和工具,包括COBIT、ITIL、ISO 27001、Prince 2 等。

对于普通老百姓而言,这些工具都有遥不可及的感觉。 人们只需要知道我们的信息化目的是什么,围绕人们的信息化工作,人们要采取什么样的制度和管理方法,让人们的信息化工作能够落地生根,发挥信息系统的作用,让信息系统能够顺利实施和运行,这就是人们身边的IT治理,而在做这些工作的时候, 会发现IT治理贯穿在人们所做的任何信息化工作的过程中,缺失了它,信息化工作就会停滞、会失效甚至会变成生活中的绊脚石。

2IT治理的作用

IT治理的作用可通过两个案例来了解。

2.1 案例一:豫北PDM项目实施

豫北在2013 年开始制定信息化规划,规划中指出,根据公司发展和信息化发展需求,要尽快建立PDM系统,从设计源头规范管理,这是信息化发展的基础。 2014 年,在公司总经理任PDM项目总监的情况下, 信息化办公室为主导单位, 技术中心为主要业务部门对软件进行了调研, 通过近1 年的对比分析,采用了PTC的Winchill产品,与2014 年12 月开始实施。 实施之初,就在人员组织架构、人员管理和绩效管理制度进行了制定和发布,其中信息化办公室派出专人跟踪项目,全程陪同实施小组进行项目推进和技术承接,同时要求各业务部门派出兼职业务管理员,负责本部门业务沟通、设计以及日常二次培训和本部门日常业务指导。 同时在服务器搭建上采用生产机和测试机方式,测试机具备与生产机同样的系统和数据,做到任何的真正实施都是在成熟的测试后进行迁移,同时也可以作为冗余设备,确保数据安全。 在软件实施中建立了详细的实施步骤,并对所有项目组成员进行了相应的绩效考核,同时制定了PDM岗位操作手册和培训手册,分批进行培训,实现技术顾问培训系统管理员,系统管理员培训业务管理员,业务管理员培训软件使用者的培训制度,充分的消化和吸收软件的功能、业务操作使用规范以及问题处理方法和系统规则。 系统上线后,制定了详细的售后服务制度流程,并利用OA系统成立PDM小组,将使用过程中所有暴漏的问题进行快速曝光处理,处理流程步骤级别依次为业务管理员、系统管理员、技术顾问(远程支持),通过持续的后续培训补充由于特殊原因的培训不到位,通过系统管理员的定期抽检排查系统来监控系统的运行状况,积极主动发现问题并解决问题。 同时还要不断地通过培训和交流让大家对软件系统的设计规则和信息化的必要性进行理解和接受,比如在PDM实施完成后的运行过程中的一个小问题: 设计规则是新品设计出的图纸分为三种状态,C阶段、S阶段和D阶段,成熟度是D大于S,S大于C,试想,当一个产品已经设计成熟,该产品的所有零部件也应该具有相应的成熟度,如果这时想借用一个成熟度低的零件,那么你的整个产品肯定就要状态发生变化,就不能再算做成熟产品了。 但是在实际工作中就是存在这种不按设计规则的情况发生,例如A产品在C阶段,由于某种原因项目停滞, 新设计B产品时借用了A产品其中一个零件,B产品正在审批进行小批量生产, 这个时候A产品也想审批小批量生产, 那么就必须等到B产品走完流程才行,因为B产品已经带着借用的A产品的零件进行审批,如果这时A产品也走审批,就会出现同一个零件在两个审批中进行,如果审批结果不同,系统就会出现短路了。 这就是对过去设计管理观念的颠覆, 可利用系统的规则进行规避所认为的一些风险,让设计工作更加成熟完善。 可能在刚运行软件后,大家的习惯和认识都还不能适应这些,但是必须这么做,必须对大家进行详细的解释,首先固化,才能创新。

2.2 案例二:豫北ERP项目实施

豫北在ERP实施后运行过程中暴漏了很多问题,例如:出现一物多码,新品档案建立滞后,档案加入后属性不对,人员权限不够,制单人员输入错误等等,所有的问题都是小问题,但是当所有问题汇总到月底或年底,会导致财务结账失败,系统会提示问题的所在,很多情况都是属于零件归类错误,物料仓库选择错误,甚至是制单和审核日期出现跨月。 在信息化进程中,数据的准确录入是构成大数据时代最为关键的一环,没有准确的数据录入,将来的库存分析,生产计划排产,商业智能决策分析都会失去意义,这样的信息化软件带给公司的不会是快速决策,不会是提高生产率,带来的是冗余无效垃圾数据,只是负担。 其实,出现的这些问题都可以避免,只是忽略了IT治理的存在,人们一直存在的思想就是 “信息化”就是买软件和上软件,上了软件就没有后续了,软件厂家的实施顾问走了,没有知识的承接和传递,也没有IT后续的治理计划,直接造成在后续的使用过程中,由于更换岗位、人员更替、缺少必要培训等等原因,造成制单人员对业务操作中的理解不够,错误率增加。 俗话说无规矩不成方圆,习主席也提出要依法治国、建立法治社会,同样,在信息化工作中也要建立岗位职责与手册,建立IT绩效管理制度,只有对信息化工作有了很好的认识,将其作为生产经营中的重要一环进行治理和维护, 才能将错误率降到最低,起到大数据的应有的效力。 所以,在信息化建设中的最大问题,不是技术问题,也不是资金问题,而是缺乏科学的IT管理观念;IT领导者最大的问题不是缺少经验和能力,而是缺乏卓越的IT管理素质和管理方法。

从上面两个例子可以看出,缺少了IT治理,项目即便是实施完成,在后续的运行中也会出现问题,而且问题会越积越多,到最终无法收拾的情况下只能导致软件的瘫痪,以至于整个项目的最终失败。

3应该如何做

如何解决中国式过马路,要建立人行道、快车道,护栏等设施,这就是基础建设。 那么信息系统就是建立高墙隔离道路,各行其道,互不干扰,但是并不是简单地建立这些就够了,还要进行治理,IT治理就是从如何建立,规划成什么样子更科学,如何提前告知人们如何行走,如何规范人员的行为,建立法治规范,避免私自打通、越墙、抄近路等违规行为,运行中是否有更好的地方要进行改善等等方面进行,最终实现目标。

因此,IT治理贯穿了IT建设的全生命周期过程中,在信息化工作中一定要构建持续的信息化建设长效机制, 包括IT组织与规划、IT建设与交付、IT运行与维护、IT评估与优化方面都要有详细的策略和方法。 只有长期将IT治理作为日常的经营管理活动,才能让信息化工作顺利进行。

参考文献

[1]涂伟.IT治理评价:在公司治理基础上的信息化水平评价[J].科技进步与对策,2007(7):180-183.

[2]吴梅磊,于菲菲.基于IT治理的企业信息化建设之道[J].管理科学与经济学,2014(9):215-216.

IT空间无大小，坚实基础最重要 篇3

然而，由于一直以来IT行业主要应用都采用组件式部署，单纯的组件拼接很难保证整体系统的可用性，因此如何确保小型IT应用能简单、快速地满足业务复杂性日益提升的需要，已迫在眉睫。显然，只有从实际的问题和挑战出发，充分考虑企业的需求，通过系统性集成，才能根本解决。

何谓Mini-英飞

对于传统的大型企业、数据中心来说，InfraStruxure英飞集成系统解决方案的确已经深入人心，其完善的IT基础设施架构和全面操控能力，都得到了业界的认同。然而，对于中小企业的IT应用环境，我们是否也可以借助类似的技术平台和架构，实现灵活的解决方案呢？

答案自然是肯定的，这也正是Mini-英飞集成系统解决方案出台的重要价值所在。它将全面实现硬件、软件的系统集成，加速IT基础设施在服务器机房、网络布线间与非专用空间等小型IT应用中的部署、配置和安装，帮助小型应用设计并构建全面支持当前及未来业务需要的IT物理基础设施。Mini-英飞集成系统，适应性强，能够根据不同客户的不同需求提供量身定制的解决方案，通过对业界最佳组件的全面集成，帮助不同的小型IT应用从容应对各种挑战

这样的方案，对于IT预算有限、技术人员不足、企业网络终端接入数量的不断增加、缺少足够空间，甚至完全没有专用IT空间的中小型企业、大型企业的分支机构、银行网点等小型IT环境的整体部署、管理、运维水平的提升，都将起到重大的推动作用。

聚焦Mini英飞

设计者显然是希望通过Mini-英飞集成系统完整呈现给中小型企业用户一个最有效率的系统设计，无论是在产品设计、安装、空间利用、操作与维护等步骤，均经过细心的推敲，通过最佳化产品规格和各项功能间的整合运作，使设计更贴近客户的需求。

具体来说，Mini-英飞集成系统共集成了11套可以灵活组合、拓展的解决方案实例，可以根据办公环境、无人职守网店、小型营业网店、中型营业网店和重要大型营业网店等应用类型进行定制划分。并从通风、服务、管理、物理安全、机架及布线管理、电源分配、供电保护等方面以智能方式全面集成，通过硬件、软件的系统性集成实现IT小型应用高效运转。

考虑到功能和投资成本的不同，这11 套方案又被细分为入门型、推荐型和效能型三大类别，以满足不同用户的实际需求。这11套解决方案中有办公环境解决方案1 款、无人值守机房1 款、中小型机房7 款。客户可以选择成型的解决方案，亦可像搭积木一样根据自己的需求选择合适的产品。布线间解决方案不但适用于新建机房，同样适用于机房改造和扩容项目。

Mini-英飞集成系统解决方案的组成部分包括

UPS：1-20KVA，机架式安装（2-6U）；

机架：24-42U；

智能PDU：机架式安装，竖装（0U）或横装（1U）；

电池柜，1/2/4小时；

网络管理卡（+StruxureWare软件）；

温/湿度监控模块；

风扇：机架安装；

具体的选型参考集。

企业可以根据自身情况，量身定制包括UPS系统、服务器机架、综合布线系统、物理安全系统、PDU、制冷以及基础设施管理和软件等在内的集成的方案，从而实现提高效率，充分利用虚拟化，有效把握商机，缩短停机时间，延长设备使用寿命，节能减排，避免断电造成的意外事故等目的。

部署Mini英飞

对于这样一套完整、灵活、强大的IT基础设施解决方案架构，部署无疑是其市场应用最终成败的关键。特别是对于那些本就缺少IT技术实力的中小型企业用户而言，如何能将这套集成系统切实贯彻下去，令其真正能为企业IT设备提供稳定、坚实、可靠、高效的运维环境，才是最重要的。

为此，Mini-英飞集成系统解决方案还特别设计了在线的产品、方案选择器，界面友好的自动化设计工具以及解决方案指南，使方案的选择和配置更加简单。通过解决方案指南，分销商、独立软件供应商、系统集成商和IT企业，无论是否具备相应的IT经验与专业知识，都能从各自不同的需求和角度出发，顺利配置并部署IT物理基础设施，从容应对挑战。解决方案指南为用户提供了常见问题的具体解决建议，并对英飞集成系统的特性和优越性进行了说明，同时阐释了该系统是如何促进业务发展以及如何让客户获益。为了帮助客户根据自身需求定制解决方案，施耐德电气还开发了两款易于使用的设计工具：其中一款用于帮助渠道合作伙伴为客户配置解决方案；另一款是供公众访问的门户网站，帮助客户从其需求和挑战着手选择最佳方案。

IT项目沟通管理 篇4

在IT项目中，要做到一个项目迅速成功的完成，并能达到或者超过预先设计好的效果，是很不容易的，在完成所下达的任务当中，设计好的蓝图跟具体的实诸于实践，既要有规定统一的制定计划，还要有一套适时的监控执行方法，但同时又不能扼杀了整个项目开发中的创造性和自主性，这样，就必须有一个灵活而且容易使用的沟通方法的过程，从而使一些的重要的项目信息时时最新，做到实时同步。

在IT项目中，许多专家都认为：对于成功，威胁最大的就是沟通的失败。与IT项目成功的三个主要因素分别为：用户的积极参与，明确的需求表达，管理层的大力支持。而这三要素全部依赖于良好的沟通技巧，特别是非信息技术人员。沟通管理的目标是及时并适当地创建、收集、发送、储存和处理项目的信息，标准的项目沟通包含沟通计划、信息传递、实施情况报告、管理收尾共四个过程。本文将谈谈一些本人在沟通管理实践中的一些经验。制定沟通计划

在项目立项后，第一步就要制定《沟通计划》，《沟通计划》应包括以下内容：

? 文件保存方式：在沟通计划中首先明确信息保存方式、信息读写的权限，明确用户信件、会议记录、工作报告、项目文档（需求、设计、编码、发布程序等）、辅助文档等的存放位置，及相应的读写权力。这样用于收集和保存不同类型的信息，有必要制定和遵循一个规定好了的统一规章制度，将与项目有关的重要工作建档。

? 联系方式：应该有一个专用于项目管理中所有的相关的人员的联系方式的小册子，其中如项目组成员、项目组上级领导、行政部人员、技术支持人员、出差定房订票等系统中相关的人员，座机、手机、职能等等，应相应的一一列上，做到简洁又要明了，最好能有特殊人员的一些细小的标注，能够做到在一打开小册子的同时就能将所有的相关人员的资料了然于胸，正所谓知已知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松做到。

? 工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相干人员的工作汇报方式，明确什么时间，什么形式。比如项目组成员对项目经理通过EMAIL发送周报；项目经理对直接客户和上级按月通过EMAIL发月报的方式；紧急汇报通过电话及时沟通；每两周项目组进行一次当前工作沟通会议；每周同客户和上级进行一次口头汇报等等。

? 统一项目文件格式：对于一个项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供编写指南。

? 《沟通计划》维护人：明确本计划在发行变化时，由谁进行修订，并对相关人员发送。

由于《沟通计划》是同很多人员有相关的，必须保证计划是有相关干系人参于制订，并且保证《沟通计划》是相当人员已经正解接收及理解。计划是用来执行的，而不是为计划而计划束之高阁。信息发送

对于项目管理的信息正确传达到相应的人员，是相当重要并有一定的困难的，经常发生的事情是信息发送人感到自己把信息正确传达了，但实际的结果却是信息没有传达到或是被错误的理解了。太多的人还是不太习惯成堆的文件或者通篇的E-MAIL传送的邮件，如果能利用非正式的方式或者是双方会谈的方式来听取重要的信息，就来得又快又准确更能让人接受，就象传统里的一纸书信在某些场合还是比任一现代化的联系方式来得好一样，价值取向不同，沟通的方式也就在使用效果上全然不一样了。

我们在沟通中应遵循彼得.德鲁克提出的四个基本法则：

? 沟通是一种感知

? 沟通是一种期望

? 沟通产生要求

? 信息不是沟通

本人在通过学习及结合实践的过程中得到以下的感受。

3.1 沟通是一种感知

沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必须有回馈机制，保证接收者接收到。比如：电子邮件进行沟通，无论是接收者简单回复“已收到、OK”等，还是电话回答收到，但必须保证接收者收到信息，并回应信息已经接收到。

信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理解了，很多信息是传达到了，但却被错误理解了。

比如：A项目经理对B项目经理说“今天我要去投标，不过我这边的现在人手少，你那边可否抽些人过来帮我壮壮声势”。

B项目经理手中有一些程序员和系统分析员，而当前程序员有些空闲人手，系统分析员今天正好有些紧急工作，但B项目经理错误理解为A项目经理需要的人是系统分析员，到时协助答辩，所以回答“不行，今天正好有紧急工作，没有办法帮忙”。

A项目经理只好另想办法。

以上就是典型的理解错误，发送方的正确表达、接收者的正确理解是非常重要的。比较简单的方式是发送者进行信息发送，接收者进行理解后进行细化并进行二次表达，但这种表达却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。

3.2 沟通是一种期望

在项目管理中，项目不同干系人是有不同的沟通需要的。

项目组成员在具体的工作安排中他想明白那个职位是否符合他的意愿等等，上级

要了解接收者的期望，向下属传达工作安排的同时还要了解他的意愿取向的问题，再采取相应的方法，调起其在工作上的热情，从而促使其在工作的高效付出，在项目管理中如让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在沟通上不得法的一个失败实例。因此制定一个协调的沟通计划就更为重要了。而项目经理的上级和客户更加关心是进度的问题：时间是否会延期、是否要添加成本、质量是否有保障等等。这对于项目经理来说，就应即时的反馈这些时间，特别是将会有延期、将添加项目成本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经理的上级和客户能及时并适时调整工作计划。

3.3 沟通产生要求

沟通是双向的，沟通必须能够符合接收者的利益，那样才有说服力。这就要求双方都要有良好的沟通方式，特别是良好的沟通又能达到双赢的目的，一致的沟通有助于组织促进项目更新。

口头的沟通能力同时似乎又是职位提升的关键因素。于是，沟通又必然的产生要求，比如：职位上成功，项目的早日完成，对问题作出恰当的回应，小到假期薪金等等都要沟通来达到目的。

3.4 信息不是沟通

当前是信息时代，必须分清哪些是沟通哪些是信息，对于用于沟通的信息必须明确简练、醒目，避免沉没于信息之海中。

信息也可用于沟通，但信息过于的生搬硬套，一个文字性的文件是并不能起到沟通的作用的，在项目中，项目经理并不是想集中于信息中而是想了解项目里工作的人员，并与之建立起相互信任的关系。而有效的发送信息，只能是依赖于项目经理和项目组成员的良好的沟通技能。

我们现在就能通过上面的四个法则来进行有效的沟通，达到保证管理中信息有效传达的目的了。实施情况报告

实施情况报告一般有三种形式：定期报告，阶段审查，紧急报告。

? 定期报告：就是在某一特定的时间内将所完成的工作量向上级汇报。在实际的项目管理中项目人员对项目经理按周报告，对于客户和项目经理的直接上级是按阶段或月进行统一的进展报告，从项目管理上讲，项目定期报告的主要内容就包括：当前是什么状态？在什么阶段？进度完成情况？当前有什么问题请上级（用户）协助解决？下周（下阶段或下月）的计划是什么等等。

? 阶段评审：在项目进行到重要的阶段或里程碑似的项目发展阶段，就要进行阶段评审。阶段评审的意义就在于评审当前的项目情况，迫使人们对其工作负责；阶段评审可以提前发现问题，提前将问题解决在初期阶段。不过阶段评审也是最容易产生争执的地方，这主要是针对于问题严重性的定级，项目经理或项目管理委员会必须在全面了解项目发展进展的情况下及时找到问题的重点，从而就事论

事的解决问题的真正症结所在，并进行后面的项目。

? 紧急报告：在出现意外情况下，进行紧急报告。紧急报告包括以下内容：当前发现的问题，相关影响，需如何解决（动用什么资源），问题紧迫性（必须什么时间内进行反馈）。

在实际的项目管理过程中，质量管理的质量保证部门也将进行质量审计，按阶段提交质量审计报告。

项目干系人接到实施情况报告后也应即时的进行反馈，明确报告已经成功接收到。并让项目干系人一道解决执行中的问题。管理收尾

5.1 项目客户验收

项目收尾期间客户将根据合同对项目进行验收，一般是对最终成果《软件系统》，项目文档《操作手册》、《安装手册》、《软件光盘》、《维护计划》或《维护手册》进行验收，双方将产生双方《项目开发总结报告》及《项目总结会议备忘录》

不同的人都有不同的见解，这些报告都是极好的资源，对未来项目的平稳运行有很大的帮助。

5.2 过程文件归档

项目组内部将对项目过程中的计划、需求、设计、源代码、变更、会议纪要、客户信件等文档整理归档，为以后的查询及参考作为一定的依据。项目档案常常在结束多年以后还有用，良好的项目档案能为当前的项目节省时间和金钱，有时还能对组织进行审计等快速提供有价值的信息。

5.3 项目总结

很多项目没有能进行很好的总结，推脱的理由有项目总结时项目人员已经不足/不全、现在有新的项目要接没有时间、写了没人看等等。这些理由全不是正确的，无论如何也要进行总结，只能总结当前，才能提高以后。

IT项目管理论文 篇5

论IT项目管理的风险分析

【摘 要】随着知识经济时代产业的飞速发展，IT项目管理中暴露出的问题也日益突出。风险管理作为 IT 项目管理的重要内容，是项目成功的重要因素。本文从风险分析的概念、过程以及方法出发，阐述了如何对对IT项目实施更加有效的风险管理，从而减轻项目风险所产生的后果，增加项目成功的机会。

【关键字】IT项目；项目管理；风险分析

一、引言

随着科学技术进步与发展、经济全球化，IT行业的竞争日益激烈。由于IT项目的研制开发需要新的技术，或使用许多已经过验证的技术和产品，但产品生产数目一般较少，这些技术和加工工艺不容易达到成熟或定型的程度。且一些大型项目的研制需要长时间大规模的组织指挥协调工作，以及漫长的研制周期等，使得难以预见的不确定性因素增多。这些不确定因素的存在使得项目能否按照预定的计划－－费用、进度和性能完成任务往往难以预料存在着失败的风险。

在我国，项目失败的现象尤为突出，大多是由于项目风险管理失误造成。从概念上讲，项目风险管理是为了使项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量等进行风险分析和管理的活动。而风险分析不但可加深对项目和风险的认识和理解，澄清各方案的利弊，了解风险对项目的影响，以便分散风险检查和考虑所有到手的信息、数据和资料，明确项目的各有关前提和假设批；还可提高项目各种计划的可信度，有利于改善项目执行组织内部和外部之间的沟通，编制应急计划时更有针对性；同时，为以后的规划和设计工作提供反馈，以便在规划和设计阶段就采取措施防止和避免风险损失。所以在进行项目管理时，风险分析是必要且重要的。

二、风险分析概念

（一）风险

风险是指活动或事件的消极的、人们不希望的后果发生的潜在可能性，指在特定的客观情况下、特定期间里，某一事件的预期结果与实际结果间的变动程度。变动程度越大，风险越大反之，风险越小。风险包含两个特征：不确定性，指风险的事件可能发生也可能不发生，没有发生的风险；损失，如果风险变成了现实，就会产生恶性后果或损失。

风险可分为以下几类：

1、已知风险，是通过仔细评估项目计划、开发项目的环境、以及其它可靠的信息来源之后可以发现的那些风险。

2、可预测风险，能够从过去项目的经验中推测出来，如人员调整，与客户之间无法沟通，由于需要进行维护而使开发人员精力分散。

3、不可预测风险，它们可能、也会真的出现，但很难事先识别出它们来。

（二）风险分析

风险分析是通过定性或定量的分析方法衡量风险发生的可能性和破坏程度的大小，对风险按潜在危险程度进行优先级排序和评价的一个过程。风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险，开发、选择和管理方案来解决这些风险的有组织的手段。本文中所说的风险分析时，都是指后一种定义。风险分析包括风险识别、风险评估、风险管理三个方面的内容。

风险识别是指确定哪些可能导致费用超支、进度推迟或性能降低的潜在问题，并定性分析其后果。在这一步须作的工作是分析系统的技术薄弱环节及不确定性较大之处，得出系统的风险源，并将这些风险源组合成一格式文件供以后的分析参考。它属于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化，并确定其严重程度，得到系统风险的综合印象。

风险管理则是指在风险识别及风险评估的基础上采取各种措施来减小风险及对风险实施监控。这也可以说是风险分析的最终目的。

三、风险分析的过程

（一）风险识别

风险识别是风险管理过程的第一步，是将项目中的不确定性及问题转换为具体的可以被描述和估量的风险，使团队可以在风险影响项目之前将主要风险揭示出来。风险只有被识别并被清晰地、明确地表述出来，项目团队才能最终达成一致意见并进而进行风险的评估和管理。风险识别过程的目标就是利用多种手段识别出尽可能多的潜在威胁，为团队创建一个面临风险的详细列表，该列表应是全面的、能覆盖项目的所有领域的、并通过提供足够信息使风险分析更具效果及效率的一个文档。

风险识别是一个反复的过程，第一轮可能是由部分项目团队或风险管理团队实行整个项目团队或主要项目利益相关者完成第二轮为达到公正，需要与项目无关人员参与第三轮。有时风险一被识别出马上就可以开发或实施简单有效的应对策略。

风险识别的方法主要有：

1．头脑风暴法，由项目成员、专家、客户等各方人员组成小组，讨论所有可能的风险；

2．专家访谈法，向项目相关领域的专家或有经验人员了解项目中会遇到哪些困难；

3．查阅历史资料，通过查阅历史资料了解可能出现的问题；

4．检查表法，将可能出现的问题列出清单，可以对照检查潜在的风险；

5．评估表法，根据历史经验进行总结，通过调查问卷判别项目的整体风险和风险类型。

（二）风险评估

在进行风险识别并整理之后，必须就各项风险对整个项目的影响程度做一些分析和评价，通常这些评价建立在以特性为依据的判断和以数据统计为依据的研究上。风险分析是详细检查风险的过程，目的是确定风险的范围和程度、它们彼此如何关联及哪些是最重要的。通过风险评估，可以制定有效的决策。

风险评估在风险识别步骤中所生成风险信息的基础上，并将该信息转换成为决策制定信息。在分析步骤中，项目团队同风险列表的风险项中新添加三个元素可能性、影响和风险值。团队可以利用这些元素来进行风险分级，并依其次序用最强的力量来管理最重要的风险。在风险评估过程中，主要注意的是由于团队成员具有不同的经验或观点，他们会对概率和影响做出不同的评定，因此团队不太可能在风险分级上完全达成一致。为了维护讨论中的客观性并减少争论，要确保在开始此步骤之前，确定作为一个团队应如何解决这种分歧。可选方案包括采取多次规则进行投票、选择最坏情况的评估或赞同对风险发生情形的处理最有经验人员的意见。

评估将风险数据转化为风险决策信息。分析为项目管理者专于管理正确的、重要的风险提供了基础。从经过排序好的主风险列表中确定顶级风险清单是一个非常有意义的工作，顶级风险清单是团队常用来跟踪风险的简单有效的技术。

风险评估的方法非常多，主要可分为定性和定量两种：

1．定性评估：定性风险评估的目的是界定风险源，并初步判明风险的严重程度，以给出系统风险的综合印象，定性地量化各种风险源可能对系统造成的破坏，从而判明系统风险大小。定性风险评价主要包括风险评估指数法RAC、总风险暴露指数法TRPC、直接风险评估法SCRAM等。其主要特点是对危险的可能性和严重程度做粗略的数值分析，大致将其划分为一些等级，然后把这两者用小同的方式综合起来衡量风险的大小及重要程度，并按大小和重要程度对风险进行分类排序，最后分别对小同种类的风险采取小同的措施，确定是接受风险还是改进设计、改善材料土艺、改变工作流程、加强人员培训以减小风险。

2．定量评估：定量风险分析是在定性分析的逻辑基础上，给出各个风险源的风险量化指标及其发生概率，再通过一定的方法合成，得到系统风险的量化值。它是基于定性风险分析基础上的数学处理过程。现发展较为成熟的方法有PRA（概率风险评估）,DPRA（动态风险概率评估）及仿真通用软件VERT（风险评审技术）等。

PRA和DPRA都是在FTA分析基础上的量化，在可靠性及运行系统风险分析领域内应用广泛。稍作改造，我们便可将其运用到项目风险分析领域。其分析步骤如下：（1）识别项目研制过程中的困难环节，找出风险源；（2）对各风险源考察其在项目研制中的地位，及相互逻辑关系，给出项目的风险源树；（3）标识各风险源后果大小，及风险概率；（4）对风险源通过逻辑及数学方法进行组合，最后得到系统风险的度量。如果是用DPRA进行评估，则尚须考虑它们在时间上的关系。

另一种被广泛运用于风险评估的方法是VERT。VERT是国外在八十年代初期发展的一通用仿真软件，它对项目研制构造过程网络，将各种复杂的逻辑关系抽象为时间、费用、性能的三元组的变化。网络模型面向决策，统筹处理时间、费用、性能等风险关键性参数，有效地解决多目标最优化问题，具有较大的实用价值。它的原理是通过丰富的节点逻辑功能，控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行，通过蒙特卡洛模拟，这些参数流在网络中按概率随机流向不同的部分，经历不同的活动而产生不同的变化，最后至某一终止状态。用户多次仿真后，通过节点收集到的各参数了解系统情况以辅助决策。如果网络结构合理，逻辑关系及数学关系正确，且数据准确，我们可以较好地模拟实际系统研制时间、费用及性能的分布，从而知道系统研制的风险。

（三）风险管理

面对风险评估后得到的风险决策信息以及风险清单，项目管理者需要对风险采取相应的措施并进行风险的监控。这一阶段的风险管理主要就是风险应对和风险监控。

应对风险时，主要有以下四种策略：

1．规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，在项目管理的过程中澄清不明确的需求、明确资源的需求量和时间、加强与各参与方的沟通，确保项目资金等。

2．转移。不消除风险，而是将项目风险的结果连同应对的权力转移给第三方。这也是一种事前的应对策略，如，将项目的成败交给监理方控制或与用户签定补偿性合同。

3．弱化。将风险事件的概率或影响力降低到一个可以接受的程度。例如，在项目正式实施之前在测试系统上多次演练。

4．接受。不改变项目计划，而考虑发生后如何应对。例如制定应急计划，当项目实施出现问题时，按事先制定好的应急计划执行。

仅仅对风险采取了相应的措施是不够的，项目管理人员还需继续进行风险监控：监视风险的状况，确定风险是已经发生、仍然存在还是已经消失；检查风险的对策是否有效，监控机制是否在运行；不断识别新的风险并制定对 策。无论项目进展的情况如何，都必须将风险管理的计划和行动结果整理汇总进行分析，形成风险管理报告。采取书面或口头、不定期的或阶段性的等多种方式，为项目的实施、控制、管理、决策提供信息基础。

四、总结

在IT项目中，风险总是和效益并存的。只有正确地识别风险、分析风险、应对风险，才能确保每一个项目的顺利实施和成功完成，并对项目的后续发展和企业的持续经营有着重要的影响，给企业带来更多的效益。

参考文献：

IT项目管理的过程 篇6

IT

项目管理的过程－方法工具技术(2006-05-11 19:13:54)

工欲善其事，必先利其器。而对于一个软件开发项目，最重要的器就是方法，工具和技术。而这三要素中重要的又是方法论，方法是基础，工具和技术更多是我们根据方法论选择的实现手段，是辅助要素。知己知彼，百战百胜。一个软件项目也一样，从项目一开始就应该分析清楚项目自身的特点，因地制宜，因时制宜的采用不同的方法论和工具技术来实现。如果这个地方就出现了决策性错误，小一点是影响项目的质量和团队效率，大一点就是直接导致项目的失败。方法论－项目的灯塔。方法论是我们针对一个行业或领域提出的分析和解决问题的方法，是我们在总结和实践过程中高度抽象出来的理论，是经过实践检验和验证的具有科学依据的原理。你的成功是因为你站在前人的肩膀上，我们不应该凭空的去发明和创造，而应该根据项目特点，借鉴前人的经验和教训，选择合适的方法论去指导我们的项目运作。让我们来分析下软件项目管理中常使用到的方法论：软件过程改进－CMM/CMMI，TSP，PSP过程改进方法论是软件项目管理中最宏观的方法论，大中型的组织或机构可以实施CMM，而对于小型组织或个人可以采用小组软件过程或个体软件过程。软件过程成熟度指针对软件过程进行明确定义、管理、度量、控制的程度。它表明软件过程能力的有效性和增长的潜力，表明组织软件过程的丰富性及其应用于项目的一致性。软件过程改进方法论类似于我们在项目中采用PDCA循环的方法，其重点在于分析和实践以及持续的改进。CMM只是告诉你要做哪些事情，但采用何种方法来做并没有明确的定义，所以CMM更像是高屋建瓴的一个东西。生命周期模型－瀑布，原型，增量，迭代，螺旋选择什么样的生命周期模型是根据项目自身特点来确定的。每种生命周期模型都有自身的优缺点。对于大中型的复杂系统，前面的需求和系统分析没有搞清楚，后面的设计和实现根本无法进行，所以这种系统还是适合用瀑布模型按部就班的进行。对于需求多变，项目进度要求紧张，人员配置相对固定，这种情况更适宜于采用增量和迭代的方法进行。分析和实现方法论－结构化分析，面向对象，面向方面，特征驱动分析和实现的方法论归根到底现在常用的就是结构化分析设计和面向对象分析设计，结构化方法强调以实体关系图和数据流图分析为核心，通过数据流图的精华和变换事务映射，进行模块和单元划分，接口分析和设计。而面向对象分析和设计强调是对象和类，关注类的属性和行为和相互协作。通过用例建模，对象的结构建模，对象的行为建模，充分考虑封装，继承等面向对象关键特征进行分析和设计。技术＋过程方法论－RUP，MSF把RUP和MSF提到这么高的地位主要还是这两个方法论是既强调过程，也强调方法的。通过过程去约束方法，同时又根据方法去改进过程。RUP既体现了用例驱动，架构为核心和增量迭代的过程核心，同时又给出了如何结合UML工具进行面向对象分析和设计的基本方法，给出了用例建模，架构建模，结构建模型和行为建模的实践思路。而MSF则是微软多年解决方案的结晶，包括了团队模型，过程模型和应用模型三方面的内容，在每一方面都有很多微软的最佳实践可以借鉴和参考，如风险管理，角色责任矩阵，每日构建等。工具和技术－提升效率的关键所在。如果你不知道去哪里？给你张地图也没有用，所以方法论更多的是让我们走正确的路。但如何在正确的路上走的更快则要借助相关的工具和技术来提高我们的生产率。现在谁用汇编语言去实现MIS系统估计不能尊为天才，而只能尊为傻子了。现在相关的工具和技术很多，主要从软件开发生命周期模型的各个阶段来谈下相关的工具和技术的使用。需求阶段工具：需求阶段主要分为需求收集，需求开发和需求管理三个方面的内容。需求收集主要是如何捕获和描述清楚用户需求，可以用Excel来完成需求的收集；需求开发对于面向对象一般采用使用ROSE工具采用UML用例建模的方式进行，用例建模一般又分为用例建模，行为建模和界面建模三个层次的内容。需求管理一般采用RP工具进行需求的追踪，采用CQ等工具进行需求变更的控制。设计开发阶段工具：设计开发阶段工具主要是前台应用和架构的设计以及后台数据库的设计。数据库设计一般采用PowerDesigner或ERWin进行数据库的建模，采用Rose，Together或XDE等工具进行架构和功能模块的设计。采用相关高效的IDE环境进行编码，或者引入一些第三方的组件或应用程序开发框架提高开发效率。同时项目也可以使用Nunit,Nant,NLog等开源项目借鉴其相关的架构和模式。测试工具：对于测试管理一般可以用TestManager进行，对于性能测试一般采用LoadRunner或WinRunner，WAS等进行。而对于系统测试一定要注意边界和异常条件的测试，相关业务流程分支的分析和覆盖。开发人员可以用Nunit进行单元测试，可以采用PureCoverage检验自己的测试代码覆盖率情况。(简略)辅助工具：项目还要配置管理，变更管理，知识库，即时通讯，MindManager，CMMI过程控制和管理等相关工具进行辅助。保证流程的规范性和可控性。

it项目管理重要性 篇7

关键词：IT内控,IT服务管理,审计

1 引言

2002年美国国会颁布一系列法案, 其中重要的404条款要求在美国上市的国内外公司建立起完善的内部控制体系, 并要求在年度报告中对其内部控制体系实施的有效性进行评价, 并由会计师事务所对其有效性进行审计并发表意见。上市公司的日常业务运营和财务管理的信息系统是企业运行的重要信息化管理平台, 因此信息系统的控制有效性将直接关系到财务报表的准确性和完整性, 信息系统的内控有效性也成为内部评价和外部审计的重中之重。与日俱增的在美国上市的国内公司已将IT内部控制的评价和审计作为企业合规工作的重要内容。

2008年5月, 财政部联合审计署、银监会、证监会、保监会发布企业内部控制基本规范, 并于2010年4月联合发布了企业内部控制配套指引, 自2011年1月1日起在境内外同时上市的公司施行, 自2012年1月1日起在上海证券交易所、深圳证券交易所施行, 择机在创业板和中小企业公司施行, 并鼓励非上市的大中型企业提前执行, 其中的企业内部控制指引第18号明确提出了对信息系统控制的规范要求, 成为我国信息系统内部控制要求的里程碑。

2 实现IT内控的标准和方法

根据SOX法案及企业内部控制规范的要求, 其最终的控制目标是促进企业有效实施内部控制, 利用信息化手段提高现代化管理水平, 减少人为因素的操作失误, 从而提高信息系统的安全性、可靠性、合理性以及相关信息的保密性、完整性和可用性。

1996年, 美国内部控制与审计协会向全球公开发布了业界普遍使用的COBIT (即信息及相关技术控制目标) , 成为业界普遍遵循的标准之一。COBIT包括4个域、34个IT控制流程和318个详细的控制目标, 从规划与组织、获取与实施、交付与支持、监控与评估4个环节进行了有效的风险管理和控制。

英国政府部门CCTA (Central Computing and Telecommunications Agency) 在1980年制定了IT基础架构库 (Information Technology Infrastructure Library, ITIL) , 目前由英国商务部OGC (Office of Government Commerce) 负责管理, 主要适用于IT服务管理 (Information Technology Service Management) 。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准, 从而使IT运营管理规范化, IT操作流程规范化。

除此之外, 还有一些国内外标准, 根据行业、类别不同可供企业参考, 如《商业银行信息科技风险管理指引》、ISO 27001等。

3 借助IT服务管理 (ITSM) 平台实现IT内控

IT服务管理平台将ITIL的理论实施到系统平台中, 将人员、角色和流程充分融合, 并有效分离各职责角色进行系统权限控制, 通过申请、上报、审批、实施、后评价等环节进行电子化控制, 实现了IT流程的自动流转, 将业务部门与IT部门以及IT部门内部之间的流程紧密联系起来, 从而有效地实现了IT内控的目标。

IT服务管理平台可以将ITIL与COBIT及相关IT标准的控制点有机结合起来, 按照企业的内部IT控制制度要求量身定制, 从而满足上市企业的合规要求。ITIL这套标准已经被国内外的很多企业采用, 全球已经有上万家企业参考此标准中的管理方法进行IT流程及系统的管理, 国内很多企业已经成功实施基于ITIL标准设计的IT服务管理平台系统 (如IBM的Maximo ITSM以及HP的OpenView) 。

4 IT服务管理系统的实施应用

4.1 背景说明

S集团是一家在美上市的中国公司, 业务发展迅速, 分子公司众多, IT控制需要满足SOX法案及企业内控规范的要求, 然而其各IT系统平台分散, 很难实现有效的跟踪和管理。目前IT流程流转是通过打印的纸质文档进行申请和审批, 传递和执行效率较低, 进度可控性差。另外, 随着集团的业务发展, 信息系统的开发、新旧系统的切换、数据中心及IT基础架构的建设要求日益增多, 没有全国集中的IT运维管理平台, 针对IT的运维管理处于被动状态, 给信息系统发展及信息技术人员管理带来较大的压力, 削弱了IT内控执行有效性。

4.2 系统实施

为了改善上述被动局面, 企业决定建立统一的IT服务管理平台, 实现事件管理、问题管理、变更管理、发布管理、需求管理、服务请求管理、合规管理的电子化控制。下面针对各管理模块的内容进行简要分析。

4.2.1 事件管理

根据集团组织架构的要求, 实现了事件管理流程的三级架构 (集团、分公司、子公司) 管理, 可以逐级上报和逐级退回, 在每一层级都可以实现事件流程的单独闭环操作。在每个层级可以根据系统分类 (如分为财务系统、OA系统、业务系统等) 或岗位职责角色 (如分为一般用户、服务台、事件分析员、事件经理等) 、不同的技术支持组 (如分为系统权限维护组、网络维护组、应用系统问题处理组等) , 不同人员角色根据权限进行操作, 互相分离又互相支持, 及时有效地处理系统故障, 从而保证企业核心业务应用系统的正常运转, 实现了事件管理的内部控制目标。此外IT人员还可以根据不同的操作权限通过“事件创建问题”, “事件创建变更”、“事件创建需求”, 实现与其他模块的自动流转, 提高事件处理效率, 规范IT流程操作。

4.2.2 问题管理

问题管理用于集中的系统事件的处理, 将同类的系统事件进行归集和分类, 统一由IT人员分析和处理直至解决。其设计与实现与事件管理流程类似, 按照职责权限不同设置为问题分析员和问题经理, 问题分析员负责问题的解决和处理, 问题经理协调问题管理的进度和时间安排, 确保问题在合理的服务管理级别内解决, 保障企业信息系统的正常运行, 从而实现了问题管理的内部控制目标。

4.2.3 变更管理

根据集团组织架构的要求, 变更管理实现了集团总部及分子公司层级的变更控制, 变更流程包括变更申请、变更构建、变更审批、变更实施和变更关闭, 按照各流程环节的角色要求设置了变更请求人、变更受理人、变更实施人、变更经理, 并且根据变更的重要程度和紧急程度设置变更顾问委员会和紧急变更委员会, 分别负责重大变更的审批和紧急情况下的变更审批, 保证了变更管理流程的申请、授权、实施、评价过程的自动控制流转和职责分离, 从而实现了变更管理的内部控制目标。

4.2.4 发布管理

发布管理主要针对集团信息系统变更后的管理, 其主要集中在集团总部信息技术部门, 根据组织架构特点, 形成了发布创建、发布计划、发布审批、发布构建和发布实施的完整流程。按照各流程环节的不同角色设置了发布请求人、发布受理人、发布实施人、发布审批人, 并根据发布的重要程度和紧急程度设置了发布顾问委员会和紧急发布顾问委员会, 负责重大发布和紧急发布的审批。发布变更有效保证了程序发布各过程中的职责角色分离和申请授权控制。此外发布管理与变更管理、需求管理及软件生命周期管理平台建立了接口, 可以由发布流程创建变更申请, 需求的结果是发布实施, 当发布实施完成时, 对应的需求状态也会同步更新, 变更管理中对应的软件生命周期平台中的发布单也进行同步更新, 从而有效地实现了系统业务系统需求提出、程序变更、程序开发、程序发布、程序实施完成的控制流转, 从而实现了发布管理的内部控制目标。

4.2.5 需求管理

需求管理将业务部门与IT部门之间的控制流程紧密结合, 实现了从业务部门需求提出、需求审批到信息技术部门审批需求分析的系统控制流转。该流程根据角色和职责要求设置了业务需求申请人、业务需求负责人、信息技术部门需求受理人、需求部门需求审批人, 通过对角色职责设置有效进行了审批和授权职责的分离, 保障业务需求开发的合理性, 从而实现了需求管理的内部控制目标。

4.2.6 服务请求管理

该流程可以实现应用系统和IT重要设备等权限或口令的申请、更改的审批授权。根据申请和审批角色不同, 设置了服务请求申请人、业务部门负责审批人、服务请求接收协调人、信息技术部门审批人和信息技术部门受理人, 从而实现了权限的申请、审批和授权, 乃至各级架构的权限审批处理和权限上报审批处理, 保障了权限及口令管理的合理性和安全性, 实现了服务请求管理的内部控制目标。

4.2.7 合规管理

此流程设置了IT人员日常信息系统维护任务, 根据各职责角色不同, 设置了日常操作人员、日常操作审批人、日常任务管理员。日常任务管理员可以按照集团及各分子公司的日常运维内容和频率进行设置, 使系统可以自动产生任务, 并设置任务提醒功能, 针对IT操作人员任务的执行完成情况由操作人员的上级主管负责审批其执行有效性, 确保IT维护人员定期执行巡检任务, 保障信息系统运行的有效性, 从而实现了合规管理流程的内部控制目标。

通过实施上述各管理模块, 不仅实现了ITIL与COBIT相融合的目标, 也完成了集团企业组织架构的重新梳理和优化、完成了系统各人员组和人员角色的梳理, 保障了人员职责角色在IT内控执行过程中的有效分离, 保障了集团及各分子公司信息的一致性, 保留了审计痕迹。因此外部审计师和内部审计师可在集团层面通过IT服务管理平台数据对信息系统变更、权限申请、信息系统维护等环节执行有效性进行审计, 节约了时间和人力成本, 增强了上市公司信息系统合规的执行力度, 降低了信息系统控制风险, 对保证公司审计报告的有效性起到了积极的作用。

5 结束语

企业通过实施IT服务管理平台, 能够将其组织及人员架构、职责及IT内部控制流程和制度进行重新整理, 建立完善的IT运行维护管理规范, 实现IT流程的电子化控制, 提高IT运维效率和IT内控整体执行有效性, 有效降低了企业的IT合规成本。为上市公司信息技术部门、内部审计人员及企业管理人员提供了IT内控实施的参考案例。

参考文献

[1]覃正, 郝晓玲, 方一丹.IT操作风险管理理论与实务[M].北京:清华大学出版社, 2009.

[2]过怡.SOX——IT部门的挑战和机遇[J].电脑知识与技术:学术交流, 2007, 1 (4) .

IT服务项目管理实践 篇8

关键词 IT服务 项目管理 责任和挑战

中图分类号： TP393 文献标识码：A

1 IT服务管理的重要性

1.1 业务的快速变化对IT部门提出了更高的要求

面对全新的业务环境，IT部门将面临多方面的压力与挑战：

（1）当业务需求更快速的变化时，如何能更快速响应业务、及时推出新IT系统？

（2）当面临更多法律法规的管控要求时，如何保证IT系统合规、安全、稳定的运行？

（3）当业务对信息技术依赖性逐渐增强时，如何实时掌握系统运行质量？

（4）当用户愈加成熟从而提升服务质量意识时，如何提升服务效率和服务质量？

1.2 IT服务管理项目组织特点

（1）广泛参与度。IT服务管理项目经理首先要明确的一点是面向业务的，与所在企业及企业所处商业环境密不可分，所以IT服务管理的推行应当秉承着作为企业资产有机组成部分原则去做。另外一点需要清晰认识到，IT服务管理不能一蹴而就，而是长期的、阶段性的、持续推进的事情，通常需要3到5年的持续改进。

IT服务管理项目咨询方的参与是很必要的，主要有以下原因：

提供专业方法论；

提供行业经验；

帮助决策；

协助推动项目；

实施指导和支持。

（2）矩阵式管理。矩阵式管理将组织按两个或两个以上维度划分，比如按照职能和流程角色。矩阵式管理的应用方式简单来说就是资源调配，需要资源了就按照某个维度去调配，用完了再还回去。

IT服务管理项目组就是个典型的矩阵式管理组织，项目团队中的成员来自不同的部门，有他们所在职能的工作还要承担项目中的相应角色并承担一定的义务，这样多种角色多头汇报的情形在项目推进过程中就难免发生“扯皮”现象了。这样本来想要提高效率的管理方式却可能导致管理成本、沟通成本增加的结果。

（3）项目组织结构。

将流程Owner角色的部门领导放在推行组，并作为项目任务的监督者，这样对增强沟通及减少“扯皮”现象会有所帮助。

1.3 考核与激励

与好的工作效果相关的三个方面：自己喜欢当前的工作，领导分配的任务不得不完成，任务会被考核并与自身绩效挂钩。项目组织结构中可以完成前两步，而在绩效与激励方面先要同老板沟通，提供2～3个适合所在企业的方案得到认同后再与人力资源讨论、落实。

1.4 动态交互性

IT服务管理项目团队的组成是甲、乙双方共同参与，双方通过高度互动共同完成知识转移和渗透，主要形式包括：

培训，管理体系培训、IT服务管理流程培训、流程设计培训、工具应用培训、实践培训等；

访谈，现状调研阶段、阶段性实施后成果访谈等；

讨论，报告、例会、临时会议、咨询等；

宣传，共同制作内刊、宣传材料、问题、内部培训等；

内审，从项目启动后就应当开始建立这种自发的改进制度。

这个互动过程起初会借助乙方的经验来运行，甲方要主动参与和学习慢慢的将经验知识转移为自己的工作内容，有明显效果的应当定位制度固化下来比如内训，比如内审。

1.5 长期性

IT服务管理项目不是交钥匙工程，不是贴标签工程，更不是可以一蹴而就的，它是对工作习惯和管理方式的改变。虽然有ITIL有Cobit等最佳实践，但还是需要根据自身业务特点因地制宜、循序渐进、稳扎稳打的落实，依据项目范围及企业规模不同可能需要3～5年甚至更长的时间进行持续改进最终与业务融合。

2 IT服务管理项目责任和挑战

2.1 主要职责

（1）炼材：选人、沟通、激励是主旋律，锻炼队伍、培养人才是目的。

企业推行IT服务管理项目，主要是解决实际中现存的问题然后是效益，但无论前后都涉及到业务领导、部门负责人、职能承担者等，那么依照IT服务管理项目解决哪方面问题、实现哪方面效益不同项目经理应当选取不同的人来参与，包括企业内部、咨询公司、厂商的人员的选取。

（2）成事。

做成一件事情涉及到多方面，企业文化、计划、组织等，说到底识别并规避风险，然而是不是可以将与IT服务管理项目相关的风险都识别出来，识别出来的是否都能解决？行业相异、企业不同、具体情况更是千差万别，这里仅说一些常见的风险。

组织架构变动，一方面人员职责不明确，另一方面人心浮躁，这两点都足以阻碍项目的推进；最好的规避措施就是等待组织架构变动完成后再推进项目，如果在项目进行中组织架构变动，为组织架构变动预留足够的时间是个明智的做法。

过度依赖咨询公司。咨询公司可以带来体系化的知识与客观的建议，可以比喻为甲方的“拐杖”，无论是对业务的理解、IT服务管理落地还是长久的应用，甲方都是主角。规避措施可以使以下几种：

拥有对企业业务有深刻理解并有丰富IT服务管理经验的帶头人；

建立一只甲方自己的IT服务管理队伍，结构上分成三个方面：包括具备IT服务管理意识的业务端、对业务端支持的IT服务管理团队以及质量体系监控方；

领导的高度重视；

熟悉企业业务的咨询公司；

明确的阶段性目标，切实可行的项目计划、WBS，以及被认同的预算。

2.2 关键技能

（1） 领导能力。

由于IT服务管理项目结构的特点，项目成员有业务或技术高层担任的管理者代表、其他部门的经理或员工。在这种情况下采取参与式或顾问式的的领导方式会比独裁式或命令式的更为有效，实际上在平衡利益、争取意见一致性方面的阻力也会较小，明确了领导方向也就给项目成功定下了一个基础。

有了适合的领导方式，就需要团结各方力量协同工作，关键在于建立“信任”。可以從以下几方面去考虑：

律己：言行一致，如果要求别人加班或者细致的工作，要让自己先做榜样；

用人不疑：授权相对于职能不要反差太大，一旦明确授权就要充分信任，建立起战友般的友情与忠诚；

正向引导：使团队成员充分了解项目结果和利益，通过生动描绘目标达成的结果使大家了解实现项目的收益。

（2）沟通能力。

IT服务管理项目经理必须是一个良好的沟通者，他要与项目团队成员、各相关部门、咨询公司、产品厂商等进行定期的沟通。只有通过有效的沟通，才能确切了解各方面实际的情况，发现潜在问题，制定解决方案，协调关系、集结资源使项目向着期望的方向前进。

（3）人际交往能力。

良好的人际交往能力可以影响周围人的思想及行为，在项目推进中IT服务管理项目经理会与项目团队成员或者高层管理者进行说服和协商工作，比如出于公司整体考虑，需要利益平衡将改进的进度延后。

（4） 时间管理能力。

良好的时间管理能力可以说是项目成功的一个必要条件，列出一些常见的时间管理技巧；

优先计划管理：按重要程度和紧急程度来确定先做什么后做什么，如：重要紧急的优先分配时间完成，重要不紧急的每天都持续一段时间做，不重要但紧急可以安排给别人做，不重要不紧急的最好不占用团队时间；

适用时间计划工具，编制计划并进行跟踪，有时候一个CheckList效果也不错；

把工作授权给他人：不必每一项工作都事必躬亲，授权给部下一样干的好而且还能锻炼队伍；

拥有良好的心态：压力并非来自已经解决的事情，而是来自未能克服的困难。

2.3 面临的主要挑战

（1） 组织结构与项目范围的变化。

IT服务管理项目不一定都会遇到组织结构与项目范围的变化，但如果你碰到了，可以肯定的是有很多事情都要变，包括指定的计划、铺垫的关系以及和领导预先的沟通甚至承诺。坦然面对这些，这种事情并非无法克服。无论如何，这种变化通常是高层管理者在变革过程中平衡公司内部各种利益的方式，从长远来看对IT服务管理项目执行和贯彻是有好处的。

（2）跨部门协调与沟通。

无论是对内提供服务的内部IT还是对外提供服务的IT服务供应商，在做IT服务管理项目的时候都会涉及到跨部门的协调与沟通。而IT服务管理主要是针对管理精准化、规范化的一种项目，推行过程中一旦涉及到利益的平衡就会有得失，相应的跨部门的沟通就会遇到阻碍。

措施：与管理者代表沟通，制定规则；定义每周例会，相关部门的流程经理都要参与，必要时也可以邀请职能经理参与；会议中可以将跨部门协调、沟通有难度的拿出来讨论，并记录会议纪要，会后将会议纪要分发至相关人员。

2.4 IT服务管理项目实施中沟通问题

IT服务管理应用场景很多，有的是运维环境、有的是呼叫中心、有的是BPO形式的对外服务，项目团队中会有技术专家、业务专家、管理专家，这样沟通的时候就会有问题。

通常技术专家在谈论的时候会用到联通性、延时、流量、丢包率、MTU描述网络性能，用DAS、NAS、SAN来告诉别人我们的存储是怎样的，或者开个玩笑“写SQL，Delete的时候竟然忘了用where”，在笑的前仰后合的时候很难说另外两组专家有何想法。

业务专家很清楚IT服务是什么，他会说我关心的是服务产品化，可以持续的快速复制，让我们在竞争环境中处于有力地位提升市场占有率，还要控制成本；当然毛利率高了他们才有收益，了解业务的技术专家会这么想。

管理专家两方面都会了解一些，而且说明问题的时候总能深入浅出“瞧，CMDB是个逻辑库，你可以把AIX想成一个装满白菜、萝卜的大柜子，而我们只要有个列表……”不过，这可能让系统管理员表情显得不自然。

这些日常的话语并非问题或者冲突本身，只是借用的一种方式，这说明我们可能忽略了一些本该有的沟通，有时是内部的、有时是外部的。

参考文献

[1] 杨坤，王玉.IT项目管理[M].北京：机械工业出版社，2008.

[2] 欧立雄，成功的项目管理[M].北京：机械工业出版社，2008.