求教IT项目论文

1解决方案难写在哪里？很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样。 因为你不敢让你的同事知道你只能用很少的一点时间写方案，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。写方案不难，知道怎么写才难。有结构就有思路，有思路就有方案。另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。基本上原因可以归为四类：11 第一种是没有体系一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。因为这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。12 第二种是没有思路有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。13 第三种是没有素材一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。14 第四种是没有层次很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。其实方案编制在不同阶段有不同策略，不要轻易提供方案。刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。想急就又能解决问题的事情，本来就是一般人做不来的。方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。21 第一个容易犯的错误：只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。所以真正好的方案，不一定厚，但能看出你用心，你认真。现在的解决方案一个不好的倾向是"长、厚、全"，看起来面面俱到，其实对决策者没有帮助。所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说"我能！我能！选我，选我！"。如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业)，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。但对内容认可程度并不高，实际上没看懂。22 第二个容易犯的错误：业务解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN(顾问式)销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。)评论(0)

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)[1][2][3][4]

善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。

重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)

测试

测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)

测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。

进度管理

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。

要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。

制定项目计划时，必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度，有利于对项目进度的管理。

变更管理

变更包括需求变更、人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而eas项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。

风险管理

要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，而一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。

成员管理

不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。

持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班，只能降低项目成员的工作效率。项目过程中，如能适当地开展一些活动，无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻，项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。

必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外，一个好的领导也是至关重要的。因此，必须选择合适的项目组长，通过他们掌握整个项目团队成员的工作进展。同时，还要了解每个成员的能力，以安排合适的角色与岗位。

重视开发组与测试组以及项目管理小组的合作。项目组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。

作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（mvp），著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 soa企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

IT项目管理

第 1 页

摘 要：本文从企业信息化建设的角度，从信息化项目建设的现状入手，强调项目选择和立项管理的重要性，详细描述了信息化建设项目启动管理的主要管理控制点，及每个管理控制点的主要措施，分析了作为IT项目的甲方，启动项目的整个管理过程。

关 键 词： 项目启动管理、需求分析、可行性方案论证

过去的几年，一些公司在信息化建设方面的投入巨大，难免有一些急于上马的项目投入与产出并不十分理想。而且由于市场环境的迅速变化，相应的业务模式也在不断的改变，从而给信息化系统的适应性提出了相当高的要求。

过去的有些项目启动时期没有很好地考虑到这些问题，造成一些项目盲目启动、仓促上马，导致项目的投入产出分析不清，项目重复建设，组织混乱，给后期的项目实施，项目维护，项目使用带来极大的风险，甚至导致系统建成后被用户弃用。最终使业务遭受损失。因此，越来越多的公司对于项目上马的决策已经趋于理性，严格要求做好项目启动前的论证工作。在满足当前紧迫的业务需求和长远的战略需求之间作好平衡。确保项目建设的成功。

相对产品供应商而言，企业在项目建设中处于合同意义上的甲方，其项目的启动过程与乙方的项目管理有很大的不同，是一个较为复杂的过程。它往往需要考虑一系列的问题，如：需求是否合理？是否有必要启动项目？项目可能带来的影响是什么？可能的投入有多大？取得的效益有多大？当前的管理模式是否能支撑？如果不能，可能要在哪些方面做好变革的准备？业界相关的产品有哪些？哪些是真正适合需求的？

因此，对项目启动管理形成统一的认知，对于实施信息化项目的企业有着非常重要的意义。

一般来说，项目的启动管理可以划分为以下几个阶段：

一、意向提出阶段

在意向提出阶段，业务部门发现需要由信息化手段来实现的业务需求，并提出建设信息化系统的期望。由于信息化项目的意向伴随着业务发展的全过程，因此，对于意向的统筹管理与规划对企业的信息化部门始终是一个难题。

对于有集中业务规划期间的企业，意向的产生经常集中在业务规划期间，比如：财年末，业务对自身的模式进行盘点期间，往往产生业务模式的改进或改革的需求，从而对信息化工具产生需求。在这一时间产生的想法或需求，往往不是很成熟，不确定性很大，后期变化的风险也很高。但这一时期，也是意向最集中，最易于统筹规划的时期。信息化部门通常在这一时期，对所有的意向进行收集，分类整理，初步形成项目建设清单。并考虑公司战略重点与资源投入的约束，对项目进行排序，以确定建设重点。

对于不在集中规划时期提出的项目意向，往往会影响到原有的整体规划与计划，各方面的论证更应谨慎，比如，项目的必要性、投入的合理性、资源到位的可能性，对已建和在建系统的影响等等。

信息化管理部门（或IT项目管理部门）可以通过建立一些制度与流程，对业务需求的意向进行引导， 尽量使意向在集中规划时期提出。

意向提出作为项目启动的一个阶段来管理，其意义就在于：对意向进行统筹规划，保证系统建设的整体合理性。

二、需求分析阶段

在受理了项目的意向以后，就进入对项目需求的分析阶段。这一阶段需要有IT人员与业务人员组成的小组，对业务需求进行详细的调研与分析。采用的方法主要包括各业务层次人员访谈、会议。

在这一阶段，IT人员与业务人员往往会出现矛盾，IT人员可能认为业务的需求不清晰，而业务认为自己的需求已经十分清晰。解决这个矛盾的关键在于，要有详细的管理控制方法，引导业务人员进行需求的细化。如，制定需求分析报告的框架，针对关键点形成文档等。一般来说，需求分析包括以下内容：

当前业务流程分析

未来业务流程分析

当前业务与未来业务的差异分析

信息化功能点需求

对将来系统的非功能需求，如：性能需求，环境需求，安全需求等

需求的优先次序

需求分析报告形成以后，还需要组织对需求的评审，以达成项目关系人对需求的一致认可。这一过程可包括：

制定评审计划：制定评审的工作计划，确定评审小组成员，准备评审资料。

需求预审查：评审小组成员对需求文档进行预审。

召开评审会议：召开评审会议,对需求规格书进行评审。

调整需求文档：根据评审发现的问题，对需求进行重新分析和调整。

重审需求文档：针对评审会议提出的问题，对调整后的需求文档进行重新审查。

三、可行性方案论证阶段

可行性方案的论证是项目启动阶段的关键活动，它的质量直接影响项目的实施效果。论证小组一般由企业内部的业务与IT技术两方面的人员组成，视项目的重要程度、难度与规模，可能还需要企业外部的专业顾问资源。

可行性方案论证的目的是通过确认管理体系和系统技术构架，从而确认未来的管理和技术方案是否有效。它立足于项目从管理上、技术上、实现上的难点进行阐述，逐步理清楚客户的需求。并在需求的基础上，规划总体解决方案，以作为项目投入产出评估的依据、产品选型的依据，以及后续实施方案的约束。

项目投入产出评估的依据：建立在业务需求分析基础上的项目投入与价值分析，往往是比较粗略的宏观感受。业务人员在提出信息化需求时，可能并没有充分考虑它与其它系统之间的关系，这样得出的投入与产出分析也是很粗略的。如果在此基础上，通过设计可行性方案，考虑清楚该项目的定位，与其它系统的关系，相信投入产出的分析将更有说服力。

产品选型的依据：可行性方案的制定是建立在业务需求的基础上，是不受任何产品影响的。因而它是后续产品选型的依据，它使得企业可以在产品选型过程中始终坚持从自身的需求和规划为原则选择产品与方案，而不至于受到供应商解决方案的误导。

实施方案的约束：可行性方案与实施方案是总体设计与详细设计之间的关系。可行性方案描绘了总体的业务方案与技术架构，而实施方案是可行性方案在各方面的细化。

此外，围绕可行性方案从管理上、技术上、实现上对难点进行的阐述，可以有效地开展项目的风险分析，制定项目的风险管理策略，为项目的成功提供保障。

四、产品选型阶段

当可行性方案需要通过选择新的产品来完成时，进入项目启动管理的产品选型阶段。在该阶段，对供应商进行初步的筛选以后，根据需求与方案要求，制定招标文档，接收供应商的项目解决方案，并根据评估标准，组织相关人员对供应商进行评估，选出2个以上的供应商进入商务谈判。并在立项报告审批通过以后，与供应商签署合同。该阶段又可细分为以下几个步骤：

创建RFP：根据需求阶段与可行性方案阶段分析的结果，制定向供应商招标的文档。

第 2 页

解决方案评估：制定产品选型评估的标准是该活动的核心，它包括：应用软件评估：对产品本身的功能、性能、体系架构、用户友好性、市场评价、费用等方面进行考察；

软件运行环境评估：对系统运行所需要的服务器、客户机的软硬件配置进行评估。这是很容易被忽略的一部分，又是有可能对后续实施投入影响最大的一部分，尤其是在客户端数量大，环境复杂的情况下。

项目实施评估：在信息系统的建设中，项目实施方法与能力已经成为项目成败的重要环节，因此对服务商实施能力的评估显得尤为重要。评估内容主要包括：实施方法、实施费用、实施周期、实施顾问经验以及对相似实施案例的考察。

培训与售后服务评估：包括考察培训方式、费用、售后服务方式、费用、响应时间等。

供应商评价评估：对供应商的基本面进行评估，如供应商的规模、业绩、合同语言和仲裁地、与客户的合作策略等方面。

效益风险评估：即项目的投入与产出的评估。这是最难评估的一项，当前在信息化项目中尚没有形成较完备的投入产出的量化评估指标，多是采用一些定性的分析与比较。

商务谈判

关于商务谈判的组织与技巧，有许多专门的论述。从信息化项目管理角度上具体来看，商务谈判是在一定的策略指导下，与产品及服务实施商进行的，确定合同条款的过程，目的是最大化的维护公司利益，确定最优的价格和服务条款。

商务谈判的依据是评估通过的解决方案，其过程通常包括：组织谈判小组、制定谈判方案、实施谈判、签署合同。值得注意的是，商务谈判与后续的立项报告审批并没有严格的先后关系，是可以同时进行的。但合同签署必须在立项报告审批完成后才可进行。

五、立项报告审批阶段

立项报告是项目启动阶段的重要文档，在这一阶段，需要将从意向提出、需求分析，到可行性方案论证，到产品选型各阶段产生的重要内容整理形成文档，并任命项目经理、建立项目组织机构，申请项目经费，然后按公司的管理流程，交相关的部门会签，成为确认项目合法性的文件。后序的所有项目活动都要以立项报告为依据。

六、项目启动会阶段

有时候，项目启动会被看作一个时间点，一个里程碑，而不是一个阶段。这里将立项批准后，项目启动准备到项目启动会结束这一过程统称为项目启动会阶段。

项目启动的准备工作比较繁琐，具体事宜取决于项目所在的管理环境的要求。在项目启动准备期，可以准备一个项目启动检查清单，以确保项目启动工作的有序，避免疏漏。一般说来，启动会准备工作包括：建立项目管理制度、整理启动会资料等。其中建立项目管理制度是非常关键而且容易忽略的一项工作，主要包括：

项目考核管理制度

项目费用管理制度

项目例会管理制度

项目通报制度

项目计划管理制度：明确各级项目计划的制定、检查流程，如：整体计划、阶段计划、周计划

项目文件管理流程：明确各种文件名称的管理和文件的标准模版，如：汇报模板、例会模板日志、问题列表等。

项目启动的准备工作完成后，就可以召开项目启动会议了。启动会议是项目开工的正式宣告，参加人应该包括项目组织机构中的关键角色，如管理层领导、项目经理、供应商代表、客户代表、项目监理、技术人员代表等。项目启动会的任务包括：

阐述项目背景、价值、目标

项目交付物介绍

项目组织机构及主要成员职责介绍

项目初步计划与风险分析

项目管理制度

项目将要使用的工作方式

从这些我们可以看出，实际上，项目启动会已经涉及到了项目计划阶段的初期内容，这也映证了在PMBOK体系中启动阶段与计划阶段的重迭。

结论：综合上述，我们可以看到，在信息化项目建设中，企业的项目启动阶段要经过意向提出、需求分析、可行性方案论证、产品选型、立项报告审批、项目启动会一系列管理活动的控制，方可完成项目的启动，进入项目实施阶段。做好项目启动管理是企业进行合理的投入产出分析，有效控制项目风险，确保项目成功的关键。

这一年马上就要结束了，那么我们在回顾之前的工作肯定取得了不少的进步。下面是由我为大家整理的“it部门年终工作总结范文”，仅供参考，欢迎大家阅读。

it部门年终工作总结范文（一）

20xx年度是技术部快速、稳步、持续发展的一年。在公司各位领导大力支持下以服务作为技术部的工作重心，努力打造安全、稳定、高效的企业网络，在信息化建设、信息安全保障、系统研发等项目中，与各部门紧密配合，顺利完成了20xx年度的工作任务，发挥了技术部技术支持的工作职责。现将20xx年度的工作总结如下：

一、年度大事件

1、 xxx机构信息化建设，xx的功能修改，逐步完善业务、人力行政、

财务等流程，使信息平台支撑公司的制度执行；

2、 ERS系统前期自行开发，后续工作外包给开发商，与开发商的技术对接及进度跟进，测试修改程序，以及数据迁移工作；

3、 MOSS系统解决方案的定制，并根据海辰自身特性，做出规划实施方案和实施周期，计划将OA个别功能集成开发至MOSS中；

4、 配合公司的种子计划提供技术支持；

5、 海辰机房高温预警解决方案；

6、 保障总部、分支机构网络安全运维，突发事件的及时响应恢复；

7、 上海分公司办公地址搬迁，网络、电话综合布线规划及工程实施；

8、 企业域名续费及备案工作；

9、 部门人员流动，做好人员及时补充，避免工作衔接疏漏可能造成的工作停滞；

10、协助公司制作绿色办公宣传报，协调xx十周年庆活动筹备工作。

二、开发组工作

（一）ERS系统开发工作：

1 发布开发商修改的ERS程序并进行测试，将错误整理成文档，提交给开

发商继续修改，循序渐进地进行这些工作。

2 不断跟进开发商修改的进度，向领导汇报工作情况。

3 分析ERS数据库和MP数据库，并整理数据库中各个数据表的结构表。

4 开发程序迁移的程序，并不断完善和改进程序。

5 分析ERS数据库和MP数据库中各个表之间的关系，按照ERS数据库的结构，将MP数库中的数据统一整理出来，时间截止到20xx年x月xx日。

（二）遇到的问题：

1 在测试的过程中发现新系统中部分功能不符合驿若工作人员使用要求，与驿若和开发商共同分析提出修改意见。

2 整理出的错误数据，在修订后仍然还会存在问题，与xx人员沟通，重新修改。

3 因旧系统中数据量庞大，尤其是新闻、广告的数据有上百万条，整理出来的数据经xx公司修订后，导入新系统中时，发现存在很多问题，有将近二十多万条数据不能导入到新系统中去。将新闻数据按照每个Excel中放xxxxx条数据整理出来，通过程序调试找出错误，提交驿若公司重新修订，再导入到新数据库中。

（三）经验积累：

1 对数据迁移的方法有了一定认识，总结出在数据量比较大的时候，一定要严格按照新数据的结构整理数据。

2 整理出来的数据，必须制定修订的标准，并对修订数据的人员进行培训，讲解如何修订。

3 需求分析能力有待提高，与开发商沟通分析问题需要提高方式方法，并针对需求找出解决问题的办法。

三、网络组工作

（一）服务器安全运维管理

1服务器安全运维，提高安全级别，病毒防御能力提升，系统优化；

2服务器及数据、程序定期备份，确保数据灾难恢复；

3机房高温预警解决方案，并实施；

4处理xxOA服务器损坏事宜，OA系统迁移工作，重新向开发商申请机器码及序列号。

（二）网络安全运维及系统运维

1保障xx、xx网络安全运维，突发事件的及时响应恢复；

2xx、xxOA及企业邮箱用户增删，流程、表单的修改；

3xx、xx员工电脑每日维护工作；

系统解决方案的定制，并根据海辰自身特性，做出规划实施方案，实施周期，计划将OA个别功能集成开发至MOSS中，并进行演示系统搭建；

5邮件系统管理维护，邮件发送错误报告分析及时解决；

6闲置、报废电脑配件合理分配利用，有效节约成本；

7机房频繁断电，请物业配合进行电力改造，技术部连续值夜班维护、服务器等设备；各部门网络综合布线调整；前台装修，协助各部门工位调整，网络、电话线路重新部署，保障正常有序办公；

10xx分公司办公地址搬迁，网络、电话综合布线规划及工程实施；

11其他电子设备的调试和维护。

（三）电话、电话程控机维护

1xx、xx电话程控机管理维护，电话终端维护；

2解决xx总机拨入拨出经常占线问题，将x总直拨加入程控机，开通程控机端口，并咨询网通关于开通中继线路的方法及相关费用；

3驿若程控机来电录音，解决来电转接无声音问题。

（四）遇到的问题

1尽心尽力去解决问题，但有时得不到理解；

2执行力仍需加强；

3部门协作不到位。

（五）经验积累

与其他部门同事沟通能力有待提高，需提升部门单元工作能力，使每一个人的执行力，对工作规划、执行、总结能力应加强。与其他部门同事沟通时应注意方式方法，争取其他同事的理解和支持。

四、部门管理、电子类固定资产管理及其他工作

1、电子固定资产日常更新；

2、每月制作《固定资产月报表》；

3、验收、分类、编号、登记、封存保管、调配、借入借出固定资产表登记；

4、IT技术部每周会议纪要，日常工作汇报，工作中的问题及下周工作计划整理；

5、新人入职管理流程，固定资产分配；

6、闲置电脑合理分配利用；

7、编排电话分机表，按最新的部门分组，电话排查，对应对话使用；

8、部门内部人事变动，员工招聘、筛选、面试工作。

五、20xx年工作计划

1、ERS系统验收，程序源码了解，为今后系统修改或版本升级做准备；

2、MOSS系统详细分析规划，与微软技术进一步沟通，对MOSS更细节了解；

3、海辰、驿若信息平台、网站、邮件系统的运维保障；

4、员工电脑的日常维护；

5、技术能力的学习提高；

6、部门人员沟通力、执行力、工作总结、规划能力的培养；

7、增进团队凝聚力，协作能力。

it部门年终工作总结范文（二）

20xx年这一年中，在公司领导的正确领导及对公司信息化建设的高度重视下，经过IT部门全员长期努力，公司信息化工作取得了明显的成效。现将20xx年IT部工作总结如下：

第一部分：取得的成绩

（一） 建立xx协同工作管理平台

为了深入贯彻落实公司关于建设“无纸化办公”和“流程化办公”的决策精神，不断提高管理效率，提高资源使用效率。

在公司领导的大力支持下，在各部门同事的配合下，xx协同工作管理平台（简称OA办公系统）一期（行政及业务合同板块），于20xx年x月xx日起全面启动。

（二） 增加服务器，为各部门提供了更加强大的工作信息平台

公司为了提高工作效率，建立强大快速的工作信息平台。

于20xx年x月购进新款DELL R71 服务器szprofit，替换以前老款R71工作服务器。老款R71工作服务器改名为szprofit-k作为金蝶财务软件专属服务器。

并于20xx年x月再次购进两台新款DELL R71 服务器szprofit-2、szprofit-oa，分别作为工作服务器及OA办公系统专属服务器。

到20xx年年底，公司共计拥有服务器x台，台式PC机x台，为各部门员工的工作提供了一个强大、快速的工作平台。

（三） 加强对 信息设备的日常维护，为各部门提供更稳定的工作信息平台。

按照公司行政部领导的工作指导 ，建立稳定、安全的工作信息平台。特别是针对可能发生的服务器损坏，人为或非人为的数据丢失，做出一下防范策略：

1 每周末对公司软件、硬件做全面的维护。

2 每周末对公司szprofit、szprofit-2工作服务器中的数据做相互备份处理。

3 每周末对公司SZPROFIT-OA服务器中的OA办公系统数据做备份。

4 每个月xx—x号对szprofit-k中的金蝶财务软件所有财务数据做备份，做到服务器中的数据有备份，如果出现意外，数据可以恢复。丢失数据总量不会超过一个星期。

（四） 加强信息安全工作，严格防范计算机病毒引起的印象公司各部门顺利工作及危害业务开展及的情况。

为防止计算机病毒在局域网内扩散，降低因病毒造成的安全风险，公司每台计算机均安装了正版的NOD32安全套装，做到从源头上防止病毒在网内扩散。

（五） 加强对 公司重大活动影音资料的整理及备份。

按照公司行政部领导的工作指导 ，加强对 公司重大活动影音资料的整理及备份，建立公司重大活动完整的影音数据库，方便后期工作需要的查找及使用。公司于20xx年x月购进索尼高清摄像机一台，并于20xx年x月购进东芝UDB3 75G移动硬盘，作为储存设备。

至今已备份的活动有：

（六） 对公司小会议的多媒体改造，提高会议室的功能性及使用率。

为了减轻大会议室多媒体的使用压力，加强小会议室的功能性及使用率。行政部于20xx年x月xx日对小会议室进行多媒体改造，在原会议室的基础上增加LED平板电视机一台，使其具备播放PPT文件和视频演示等多媒体功能。

第二部分：工作中的不足

（一） 自我知识匮乏，缺少专业技术知识及管理知识

在20xx年的工作中我感觉到自己专业知识、管理知识的匮乏，今后我将要在这两个方面加强学习，提升自身综合素质，全面发展

（二） 工作缺少组织能力

在20xx年的工作中，我感觉到自己的工作比较忙乱，往往陷入琐碎的事务中不能脱身，有时难免顾此失彼，缺乏对工作的组织能力。今后我将要在工作中善用零星时间，继续进行高效的时间管理，按照工作重要性、紧迫程度合理分配时间，尽量做到及时完成领导交代的工作。

（三） IT部人员不足

20xx年公司新增加服务器三台服务器，软件系统两套，硬件及软件维护工作量在明显增大。

现IT部门的日常维护有：

1 三大软件系统（公司日常办公系统、OA办公系统、金蝶财务系统）

2 硬件设备有服务器四台（szprofit、szprofit-2、szprofit-OA、szprofit-k），终端机75台，财务独立PC机x台、总裁个人专用电脑x台，LED大屏幕一块及配套电脑x台，打印机及复印机x台，电视机x台。

3 主干网络路由器及其它网络设备。

4 视频会议设备4套（深圳2套、济南1套、上海1套）

特别是今年新上OA办公系统，维护量明显增大，现在信息部门出现人手荒的情况。

（四） 软硬件设备不足

1 服务器安全备份

至20xx年年底，公司共有服务器四台，其中工作服务器两台（szprofit、szprofit-2）程序服务器两台（szprofit-oa、szprofit-k），而服务器与服务器之间缺少安全备份及紧急恢复系统系统。当某一台服务器出现硬件故障或软件故障时，另外一台服务器很难马上作为备用服务器充当主要工作服务器的角色。特别是工作服务器szprofit和szprofit-2，公司同事的全部的日常网络办公全部集中在这两台服务器上，一旦出现服务器故障，将会导致出现工作混乱、停止的情况。

2 网络安全

随着公司的发展，公司的网络环境也起着变化。公司网络环境已经从基本半封闭的局域网办公，发展到现在由两套完全对外开放的办公软件系统（OA办公系统、金蝶财务管理软件），组成的现代化网络办公网络。

但是随着网络环境的变化，我们也将面对更加复杂的网络风险，诸如病毒、蠕虫、木马、黑客入侵等对网络安全的危害。

而我公司现在的网路安全方面主要是针对网络及计算机病毒安装了“NOD32网络安全套装”，其主要功能在于对计算机病毒文件及木马进行查杀。但是对于网络攻击，黑客入侵等网络威胁，就显得有点捉襟见肘了。

第三部分：20xx年IT部信息管理工作的思路及工作目标

（一） 梳理OA办公软件业务流程

根据公司领导的工作指导及公司新的组织框架结构，重新梳理公司OA办公系统的业务流程，并对其优化处理，在不影响公司领导办公的情况下，尽量简化步骤、缩短流程，加快处理速度。

整理方案：

1 梳理OA流程，以模拟的形势将流程全部走一边。

2 将重新制作的OA流程做成PPT文件，并要发给每个部门负责人。

3 按照各部门负责人提出的意见修改流程，并上报公司领导，做最终确认。

4 流程确认完成，做成《OA简易 *** 作流程》PPT文件存档，放到公告栏中以便大家快速，便捷的处理OA上的 *** 作问题。

（二） 增强IT部门的服务意识

缩短从接到故障问题报修到问题解决的时间，保证每天服务器的稳定工作及网络的畅通。

增强责任心，为公司领导及各部门的同事提供优质的服务，努力做到满意一百、零差错，全面提升服务质量，树立良好的部门形象

（三） 提高IT服务水平

不断学习提高业务技术水平、注重积累。将每日遇到的问题及处理办法进行记录，对常见问题及处理办法进行归类。对常见故障整理出《常见故障问题检查、处理流程》，放到公告栏中以便大家快速，便捷的解决问题。

（四） 完善IT部门的工作流程及各项规章制度

完善设备从申购、购买、入库、出库、到后期维修、报废的工作流程及相关各项规章制度。

增加从公司文档权限变更，OA流程变更、公司内网数据变更、公司数据拷贝等事宜的相关流程及规章制度。

建立一套完整的IT部门管理制度，将IT部的工作细致化、流程化。

（五） 建立完整的IT部资料

按照行政部领导的工作指导，根据每个公司员工从个人使用的台式电脑到对应的物理地址、个人所属的IP地址、电话号码等信息，建立完整的网络信息资料库。

第四部分：总结

在20xx年这个新的年度里，我将改正过去工作当中的不足，强化专业技能，不断提高自身综合素质，更加努力的完成工作，为公司的发展做出贡献。

it部门年终工作总结范文（三）

紧张而有序的一年过去了，在公司领导及各部门各同事的帮助下，我部门顺利的完成了本年度的工作，

it部年终工作总结。为了今后更好的工作，总结经验、就本年度的工作总结如下：

一、在夏天高温的天气里，由于公司弱电井散热的问题，交换机频繁死机，导致网络不通。影响收银系统和监控系统不能正常工作，针对此问题，我部门先后申请更换了3台有故障的交换机，并且配合工程部门对弱电井做了散热改造，基本缓解了此问题。

二、在公司实施FOXMAIL软件办公制度，目的是节约纸张，节省公司资源，强化公司员工的工作效率和执行力。

三、每日的收银系统维护和各个银台的障碍排除，保证公司的正常运营和收银系统安全：

a软件故障：深入检查出现软件故障计算机的问题原因。对故障现象进行记录，对故障现像进行分析，在找到故障原因后，对故障进行处理。

b硬件故障：检查出现硬件故障计算机的问题原因。对故障提出处理方法和见意，写出维修报告和配件更换，处理故障完成后，分析故障原因，避免下次出现同种情况。

四、每日对K3维护，定时对K3数据库进行备份，以及将其刻录成为光盘保存，确保公司金融安全。

五、按公司要求，开发公司的形象网站。对外宣传公司形象，与客户可以在网络上互动，增加公司知名度，方便公司对人才的招聘，为公司以后的网络销售渠道打基础。

六、每天早上晨会前，去监控室检查所有监控头是否正常运转，检查所有楼层网络是否通畅，如果有任何问题，一定在商场营业前排除，坚决不让商场在营业期间出现任何监控死角，确保公司的安全。

七、办公区电话线路和网络线路的维护与安装，确保公司所有电话和网络线路的畅通。

八、条码会员卡已经完全更换为新式的磁卡会员卡，以后会员积分就可以在收银台上完成，超市的会员系统也并入商场的会员总系统中。建立了完善的会员卡数据库，确保公司的会员制度的公平和完善。

九、公司内部人员在圣蒙系统内的权限变更，确保公司系统内部的各项职权分配，建立完善的系统办公权限模块。

十、楼下商户在圣蒙系统里的资料建立，合同签订。商品编码和商户编码的创建，为商户的正常运营带来了方便，也为公司对这方面的管理创造了便利。

十一、配合圣蒙系统软件开发商对我公司的圣蒙系统升级，保证系统的正常使用，添加了多项功能，方便了日常工作。

辞旧迎新，在总结本年度工作的同时，针对部门不足之处，对明年工作也提出了初步设想：

一、公司监控系统图像模糊，明年公司对此项目将要进行大改的时候，我部门将配合相关工程人员，将每一根数据线都标记清楚，做到能发现问题及时处理。

二、监控系统施工时，我部门要合理规划弱电井，不要使其线路杂乱无章，出现问题查找根源很麻烦。同时也要保证解决弱电井的散热问题，要从根源上彻底完结，保证公司收银系统的安全和稳定。

三、配合相关部门合理开发我们自己的网站，做好网络上的对外宣传和人才储备以及招聘。

四、继续完善公司的网络环境，为公司的再度拓展提供一个好的安全的网络平台。

我部门是一个枢纽级部门，每个部门有关电脑的工作都离不开我们，所以我们寄托着公司发展的重要责任，我们要发扬不怕苦不怕累的工作精神。在以后的工作中，大大加强业务学习，提高网络技术，努力提高工作水平，适应新形势下本职工作的需要，力求把工作做得更好。

以上就是关于IT售前人员如何写解决方案全部的内容，包括:IT售前人员如何写解决方案、互联网IT项目的管理心得体会、求教IT项目论文等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！