银行IT系统的质量控制_银行IT系统

2012-9-24 如何编写ＩＴ项目方案 通过学习如何编写方案，让大家进一步体会管理线索在实际工作（项目）中的应用。 帮助大家更容易地理解ＩＴ项目管理的理论体系：九大知识领域和五个过程组。 帮助大家学习掌握ＩＴ项目方案编写方法。 目录 什么是方案 如何编写需求分析 如何编写方案设计原则 如何编写解决方案 如何编写实施方案 如何编写维护服务方案 如何编写培训方案 如何编写典型案例 典型设计方案分析 方案就是解决问题的方案。 方案有：用户解决方案、项目申报方案、可行性报告等等。 写方案的目的就是让别人知道，你有能力高效、低耗、低风险地完成特定的任务目标。 方案中要解决： 为什么做 做什么 达到什么效果 谁来做 怎么做 花费多大代价 有何风险、怎么控制 质量如何保证 你是否有相应的能力 什么是方案 方案的背景，讲述当前与方案相关的社会、需求、技术等背景情况，国内外同类解决方案的情况等。一般出现在申报方案。 需求分析，即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 方案的意义，高度概括，这个方案能解决什么问题，方案的实现能带来什么好处。一般出现在申报方案。 方案设计原则，就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 遵循的标准，包括国标、行标、地方标等，也是在设计方案是不能突破的尺度。 方案的目标，总体概述解决问题的方案，高度概括。一般出现在申报方案。 解决方案，给读者阐明怎么做，来解决问题。是解决方案的主体。 方案有以下要点或组成部分 组织架构 实施方案（进度计划），给读者阐叙做的具体步骤，工作路线。 服务方案（服务计划），给读者阐明你有服好务的具体措施。 培训方案（培训计划），给读者阐明你有做好培训的具体措施。 沟通计划 质量控制计划 风险识别和风险控制计划 设备采购计划 工作量估算和人力资源成本预算 典型案例介绍，给读者证明，你已经具备了实现这个方案的能力。 工作基础、工作成果积累，进一步论证你具备实现这个方案的能力。 满足用户的需求、满足招标文件中提出的所有要求是编写方案的基本原则，要对用户和招标文件的每一项要求都有明确的响应，要清晰准确地领会用户的意愿，不能随意抵触或反对用户的意愿。 要努力在方案中体现我们的特点（特别是主要竞争对手所不具备的特点），要在方案中发挥我们有利的资源，厂商产品选择是要考虑利润最大化和商务可控性。 需求分析即问题所在或方案的目的，讲明这个方案要解决的问题是什么，方案都是有目的的，在这里就是要阐明目的，并树立起要解决问题的目标。给读者阐明为什么做。 用户需求分析总会是用户解决方案的第一部分，这部分主要是分析用户项目的需求、用户的关注点和兴趣点、用户当前的资源情况和存在的问题等等。 用户需求分析是整个方案定基调的部分，是为我们为什么提供后面所描述的方案设定论点并为提供论据奠定基础。 同时，到位的需求分析，也是为我们制定方案的设计目标提供依据。 作为方案的开篇部分，如果分析到位，特别是用户的关注点和兴趣点分析到位，会立即引起用户的共鸣，迅速把用户吸引住，也更容易让用户理解我们后面的内容。 一个到位的需求分析，是一个好方案的一半。反过来讲，如果你都不能全面地把握用户的需求，你拿出来的方案也不会有什么针对性，用户不会感兴趣。 要做好需求分析，需要进行耐心细致的用户调研工作，而且根据用户项目的特点，制定明确的需求调研线索和方案。 需求分析 用户立项的宏观背景 用户立项的目的和意义 用户的组织架构 用户当前it建设的情况 采用的技术需求 软件功能需求 软件性能需求（质量需求） 平台环境需求 安全方面需求 项目风险识别 用户关注点和兴趣点详细分析等 每一部分根据需要，可以做进一步分类描述。 对于一个综合性IT应用解决方案，如金保工程方 案，需求分析应包含以下几个方面的内容 大家要注意，用户需求是多角度的 在进行需求分析描述时，各部分分类要清晰 多用条理性描述少做长篇论述 各部分内容分量要均衡 要点要清晰准确 要体现全面、到位和重点突出。 大家记住，这里每一部分的描述都将是后面相应内容的线索和论据。 用户需求分析往往是方案编写者最容易忽视的部分，好多人都是随便凑点内容，甚至凑一些根本无关的内容。 这样的后果是，因为自己不重视，也就不能真正地掌握用户的需求和期望，写出的方案针对性不强。 方案设计原则是每个方案必须的部分，也是很多方案编写者最轻视的部分，好多人的办法是随便抄一个其他方案的原则部分，应付了事。 这反映出他们根本不知道原则是什么、原则的作用是什么。 方案的设计原则是设计者对设计思想的纲领性的描述，是对需求的高度抽象和概括，是进行方案设计的最基本的指导方针。 就是在设计解决方案时，必须要遵循的原则。所谓原则，就是不能突破并必须严格遵循的尺度。在每个具体的解决方案中，都要体现预先确定的原则。 在方案设计原则中，要表明在方案设计时重点要考虑哪些问题，要突出对用户关注点和兴趣点的对策，这些内容要与需求分析的相关内容紧密呼应。 方案设计原则的编写可以分为两大类，一类是基础性原则，一类是响应用户特殊需求的原则。 方案设计原则 基础性原则在每个方案中基本都会有，如： 先进性与成熟性的原则 先进性与保护投资的原则 安全性原则 功能完备性原则 灵活性原则 可维护性原则 可扩展性原则等等。 基础性设计原则 我们拿可维护性原则作为例子分析一下“原则”的含义 可维护性的意思是，根据我们提供的方案开发出的系统，具有方便进行维护的特点。 换句话讲，我们进行方案设计和开发时，要充分考虑今后维护的方便可行。 即便这些基本性原则可能在很多方案中都有，但也要充分理解用户的期望。 如用户项目资金充裕，那可能就要突出先进性的原则 反之，可能就需要充分考虑原有设备的复用，保护原有投资。 用户特殊需求的原则要认真下一番功夫 直接体现我们是不是重视用户的想法 是不是真正理解他们的需求 要想做好这方面的文章，就必须对用户的需求、用户的关注点和兴趣点非常清晰。 一般情况下，在介绍方案时，原则部分会有比较强的冲击效果，特别是那些很到位的响应用户特殊需求的原则。 说白了，就是告诉用户，你关心什么，那么我们就将在方案中注意、解决和实现什么。 解决方案这部分是方案的主体部分，也是分量最重的部分。需求分析部分是讲为什么设计这样一个方案、这个方案要解决什么问题、有什么意义。 方案设计原则部分讲的是我们在进行这个方案设计时应该遵循的原则，或者说是应该重点关注和考虑的问题。 标准规范部分讲的是方案设计的应遵循的标准规范。 这部分是介绍我们设计出来的结果。 是不是满足需求、是不是能够解决用户的问题、是不是遵循了原则、是不是符合相应的标准规范，全要在这部分中体现出来。 解决方案 为了让大家容易理解，我在这里用一个大家比较熟悉、比较容易联想的方案设计例子进行介绍，这个例子就是一座大楼的设计方案。 设计一座大楼是一件很复杂的工作，要考虑大楼的功能需求、外观、空间、每个楼层的房间布局、强电线路、弱电线路、供水线路、供暖线路、排污管线、各种材料等等，要进行力学分析、结构分析等，可以说设计一座大楼是一项庞大系统的方案设计工作。 后面将给大家介绍一下编写这部分内容的注意事项。 首先请大家记住，我们这里讲的设计方案，是我们与用户沟通交流的方案。 目的是让用户知道我们有能力、有措施、有保障地去实现他们的需求，是让用户树立起与我们合作的信心，但并非是一个具体的开发方案。 因此需要重点突出而不需面面俱到，不需要或者千万不要落到具体的细节上，要尽可能保证各部分内容的均衡。 设计方案编写要点之一 在方案描述部分的最前面，要有一个方案的总体描述，可以称为总体设计方案。 或成为方案蓝图 也就是项目的总体目标 这部分是对你的设计方案的高度概括性介绍。 设计方案编写要点之二 为了能让用户了解你的方案的全貌 对于比较复杂的设计项目来讲，不是几句话几段文字可以表述清楚的 需要站在不同的角度、针对于不同的层面进行介绍 譬如说大楼的外观，从正面看，你是看不到全貌的，即便你把外貌全介绍清楚了，如果不介绍其他的话，别人也很难明白这个大楼。 因此要学会角度、层次的分解 可以从类别上分，也可以从功能上分，分的目的是为了更全面、更清晰、更容易地给大家介绍你的方案。 一般一个ＩＴ项目方案包括： 技术架构 网络架构 安全架构 功能架构 性能指标 。。。 设计方案编写要点之三 对你的方案进行分解描述时，要充分考虑前面需求分析的内容。 需求分析中提到的需求和问题，在方案描述部分都要有相应的解决方案，前后呼应，前面讲为什么要做，这里讲怎么实现。 与需求分析呼应，也是方案分解描述时进行分解的参考依据。 方案是否与需求相呼应，意味着方案是否扣题。 有很多这方面做得不到位的方案，对在这个项目上行，按在另外一个项目上也行，就成大笑话了。目的性强！ 设计方案编写要点之四 对于一些用户关注的问题和需求，以及通过分析具有比较高复杂度的问题，也要分解出来进行单独讲解 一是表明我们对用户的需求的充分响应 二是表明对需求理解的深刻，尽管有些问题很复杂，但我们有可行的解决方案。 借此增强用户的信心。 设计方案编写要点之五 要与前面设计原则部分相呼应 在方案的描述中，要体现出我们是严格遵从前面制定的原则的。 同样，也要对所遵循的标准规范有呼应。 设计方案编写要点之六 多采用图示的方法 大家都知道，无论文笔怎么好，文字的东西总是比较抽象的 读者必须通过联想才能理解你描述的含义。 如大楼的外观情况，如果文字描述，很可能长篇累牍地写了一大堆，别人还是搞不明白。 而用图的形式，可能只需三两张图，就把大楼的外观展现的清清楚楚了。 图示的作用是直观。 图是对方案的高度概括和抽象。 做一张好图，要基于你对方案完全了解和掌握，也要基于你的知识和经验的积累。 真正好的方案描述都是图文并茂，用文字辅助解释图中关键的部分。 设计方案编写要点之七 要学会使用表格进行描述 与图示一样，表格也是一种非常好的方案描述的方法。 表格的作用是简练、调理、清晰，更容易让读者理解你所表述的内容。 对于一些包含大量数字，或者描述形式重复的内容，都可以采用表格的形式描述。 设计方案编写要点之八 对于一些重要的指标或用户关心的指标 需要基于你的方案进行分析 用合理的分析模型和数据 证明你的方案能够达到用户所期望的指标 例如设备配臵选型设计，用分析的指标作为依据 设计方案编写要点之九 对于一些需要利用其他厂商产品进行集成的项目 要讲明你所选择的原因和这些产品的作用 要对你所选择的主要产品从功能和性能角度进行介绍。 设计方案编写要点之十 为了突出我们期望让用户产生深刻印象的内容。 可以在方案描述的最后一部分做一个总结，可以用方案特点介绍的说法。 在特点介绍中，要突出我们独有的特点（在一定程度上会让用户去找我们竞争对手相关的内容）。 要突出用户关心的问题（与需求分析呼应）等， 大家需要注意，特点一定要“特”。 方案特点组织的好，也会对用户产生比较强的冲击力。 设计方案编写要点之十一 编写方案的时候，特别是编写这部分方案的时候 切记千万不要凑材料，这个地方抄点那个地方摘点进行拼凑，这是编写方案的大忌 如果需要摘抄一些资料，必须自己完全掌握这些资料的内容 并且确认对解决特定的问题有帮助。 设计方案编写要点之十二 开发实施计划，也称总体进度计划，是对全部相关计划的有机整合，也叫整体计划。 整体计划涵盖了开发计划、实施计划、采购计划、质量控制计划、风险控制计划、项目团队建设计划、验收计划、服务计划、培训计划等等。 项目开发实施方案（计划或工作路线） 我们常说，要完成一件事情，需要有计划、有组织、有措施、有保障地进行。 我们的设计方案完成后，接着就要给用户介绍我们怎么实施完成，这就是实施方案。 实施方案的编写需要按照有计划、有组织、有措施、有保障的线索，基于项目管理的思想进行阐述。 在这里对大家有一个要求，就是你在写出来这个实施方案之前，你已经真正明白了这个项目到底怎么干才能干好。 如果你都不知道怎么干的话，写出来的所谓的实施方案是不是可行就需要打个问号了。 这个问题在很多人在写实施方案时常犯的错误。 我们需要基于项目管理的思想来描述开发实施方案。 首先需要明确项目的目标。其实方案确定好了，总目标是非常清晰的，那就是按照用户的需求开发出系统，按照用户的时间约定部署实施完成。 但如果仅仅这样讲，那只落在了总目标的口号上了。 为了拿出真正可行的方案，需要把目标进行分解，分解成一个个阶段性目标或历程碑性目标，这项分解要尽可能的准确和详细，目标越清晰具体，越容易找到实施方案。 要反思，如果这一个个的阶段性目标都实现了，是不是就能很好地完成和实现总目标，如果是，说明你的分解基本就是合理的。 当目标分解工作完成后，各个子目标之间可能存在时序关系，也可能存在其他关联关系，为了完成每一子目标都有相应的工作内容、也需要一定时间和人力资源的支持，有一些比较复杂的工作可能需要一些方法的指导（工作预案）。 对应于每个子目标，把这些相关的东西搞清楚描述出来，然后按照时序关系排列起来，项目的实施计划就出来了。 实施计划描述需要调理，一般可以采用表格的形式。 目标分解一般是采用自上而下的方式进行 具体做法是，先围绕总目标的实现分解成几个大的阶段 然后对每个阶段进一步分解成更小的阶段 最后落实到每一项工作任务的目标上。 在实施计划中，还有一点非常重要，就是必须满足用户工期的时间要求。 项目组织架构 不管目标怎么定，方案怎么做的，有一点是确定的，就是必须要有人去按照计划 去干，去实现一个个的目标。 作为一个好的实施方案，需要对承担这项工作的队伍、人员进行组织和分工。 描述这部分内容的线索可以这样。 定义项目实施过程中的角色，根据实施计划的需要，对参与项目的人按角色进行分类，定义角色的责任。 分析一下这个项目每一个子目标实现过程中，都需要涉及到哪些类型的人，这些人与我们的那些部门有关。 设计项目组的管理架构，与实施计划相关，与工作分类和角色分工有关，要有责任明确的项目负责人角色。 如果队伍比较大涉及的部门比较多的话，项目负责人就需要具有比较强的资源协调能力，明确项目总负责人和不同类型工作的负责人。 根据计划的需要，选择明确项目成员。 一个好的实施方案，除了给用户讲清楚怎么干以外，还要介绍你的这种干法是可行的而且是风险小的，这就是实施方案的保障措施。 一般情况下，应该包含这样一些内容： 沟通协调措施，要有明确的沟通协调机制保障，项目是需要我们与用户、厂商、监理等一起配合完成的，因此必须要有良好的沟通。 质量要求和质量控制措施。 风险分析以及规避风险的措施。 预算（成本计划），包括设备采购计划和人力资源成本预算。 一些复杂工作的工作预案，要让用户知道我们是有办法有能力完成这些工作的，增强用户的信心。 验收计划 这是对双方都负责任的约定，验收方案要科学合理，要具有可 *** 作性。 对于一些特定的项目，需要对我们投入的人力和工作量进行统计。 首先，你要对用户参加培训的人员进行分类 不同类型的人员需要接受不同的培训 大体可以从系统管理角度和系统使用角度进行分类。 如系统管理员（进一步也可细分为应用系统管理人员、系统环境管理人员等）、系统使用人员（或者称用户业务人员，包括各个层面使用系统的人员）等。 培训方案要点之一培训对象分类 从管好和用好的角度，设计培训的课程 在每一门培训课程中，要对一下项目进行定义 培训课程名称 培训目的和期望达到的目标（培训完了，受训人能够达到什么水平或能力） 受训人技术基础要求 培训形式（集中上课、上机实习） 培训课时数 培训教材（必需要有明确的培训教材，除了编写或购买的教材以外，可以多选用项目交付时提供的资料，如设计方案、用户手册等） 培训内容概要（要介绍这门课程的主要内容）。 培训方案要点之二培训课程设计 根据项目总体的实施计划安排，设计课程表 课程表中要明确时间、地点、培训对象、课程 因为这里面要考虑总体进度，要考虑参训对象所受的时间、地点的制约 课程表的编排一定要合理可行。 培训方案要点之三培训课程表 最后可以介绍一下承担培训工作教师的情况 对几个主要培训教师的简历进行介绍 另外，对于一些需要比较特殊条件的培训，介绍一下我们的保障措施。 培训方案要点之四培训教师介绍 用户对维护服务的期望是： 平时通过有效的管理和监控，尽可能地减少故障概率 系统发生故障时，出现的问题能够得到最高效率的解决 这也是我们设计维护服务方案时的基本原则和目标。 维护服务方案 服务需求分析，对用户的服务需求，从主要服务项目和特点、响应时间、期望等进行比较详细的分析。 维护服务方案要点之一服务需求分析 组织管理体系，告诉用户我们公司有哪些部门、哪些人员以什么样的角色参与维护服务工作，每个角色的职责是什么。对服务组织中的核心成员进行介绍。 维护服务方案要点之二组织管理体系 服务项目定义，对于用户的服务需求进行应对，告诉用户我们围绕这个项目，能够提供什么样的服务工作，每项服务工作的含义是什么。如，我们有什么服务是对应于减少故障的，有什么服务是对应于解决问题的。 维护服务方案要点之三服务项目定义 这部分介绍的是为了完成我们提供的服务项目，我们有什么样的措施进行保证。 如，对于我们所提供的减少故障的服务，我们采取什么样的措施来实现。 服务项目和服务措施是紧密关联的，共同来表述我们能给用户什么服务和怎么给用户这些服务。 响应时间定义，这是对双方都有益的一个约定，介绍在不同情况下我们的时间响应措施。 维护服务方案要点之四服务措施手段定义 介绍从服务请求到服务结束我们的工作和管理流程。 进一步让用户明白我们拥有一个严密的服务体系，能够满足用户的服务需求。 需要的话，可以对服务流程所需的管理工具进行介绍。 维护服务方案要点之五服务流程介绍 前面把我们服务体系的服务组织、服务措施、服务流程介绍完后。 最后要针对于用户对本项目特定的服务需求进行响应。 设计满足于用户服务需有的服务方案。 这部分要对用户或招标文件中的服务要求进行点对点的应答，必须明确承诺是正满足。

前段时间Gartner公布了2019年首席信息官议程调查（The2019 Gartner CIO Agenda survey），共收集了来自全球89个国家与地区的逾3000位首席信息官所提供的数据。

数据显示：商业智能和数据分析将成为2019年CIO的首要预算投入领域。

2019年投入新资金或追加资金的前五大领域

①商业智能与数字分析（business intelligence and data analytics）——42%

②核心系统改进与转型（core system improvements and transformation）——33%

③人工智能与机器学习（AI and machine learning）——33%

④网络安全与信息安全（cybersecurity and information security）——32%

⑤数字化业务计划（digital business initiatives）——30%

作为新一代智能BI服务商，观远数据致力于践行AI+BI服务理念，通过敏捷化（Agile）、场景化（Accurate）、自动化（Automated）、行动化（Actionable）、增强化（Augmented）的5A实施路径，为企业客户提供新一代数据分析及商业智能解决方案。

在IT系统的需求分析阶段，保证项目以业务需求为目标; 在系统交付时，进行充分的功能测试和性能测试; 在运行阶段，保持对系统的监控，这是进行IT系统质量管理的关键。 IT系统作为银行业务的有力支撑，越来越受到重视，各家银行纷纷通过改善IT系统来节约实施和维护成本，提高客户的满意度和增加收入。但是，随着IT系统的建设越来越多，结构越来越复杂，如何保证IT系统的质量，使其真正能够满足日益发展的业务需要，逐渐成为各家银行重点考虑解决的问题。具有雄厚资金实力和IT投资预算的大型商业银行，已经开始着手IT系统和软件产品的质量控制和管理建设，制订出从业务需求到开发、测试、部署以及产品和系统上线以后的实时监控等一揽子规划，并且开始着手购买各种软件和工具进行实施。但是对于大多数银行，每年的IT预算有限，如何保证IT系统的质量面临不小困难。笔者结合目前国际上流行的质量控制和管理趋势，根据自身在银行方面质量管理和控制项目支持的经验，提出一个分阶段分步骤进行建设的建议，以供广大银行的决策者及相关人员参考。

测试工具的选择

银行作为一个特殊的行业，对于IT系统的功能性要求和性能性要求都比较高。对于银行IT系统，功能上不能有丝毫的马虎，客户交易必须正确记录，决不允许错记、漏记，如果发生错误，对于客户是经济损失，对于银行来说则是信用的损失。性能上为了提高客户的满意度，在各种渠道上都需要保证在一定的时间内完成交易，如果客户存取一笔款项需要花费很多时间，那么客户对于银行的抱怨是无法想象的，很有可能使这位客户转而投入其他银行的怀抱。从技术上说，对于功能和性能方面的质量都必须通过测试来进行验证，这是保证IT系统在功能和性能方面能够满足业务需求的基础。在功能和性能方面的投资可以优先考虑两个方面: 测试管理工具和性能测试工具。

软件测试目前作为软件工程中的一个重要的环节受到各个企业的重视，并且大家也普遍承认，这是一个需要进行有效管理的过程，因为其中涉及到测试需求的选择、测试案例的设计、测试执行的管理以及缺陷跟踪的流程等多个方面和环节，如果还停留在依靠手工处理、电话或者邮件通知、人工收集数据、使用Office软件来进行统计的阶段，那么工作量相对来说是很大的，而且不能及时反映整个测试阶段的进程和情况，因此在准备进行测试时，选择一个业界承认的优秀的测试管理工具是很有必要的。

选择一个好的测试管理的意义在于:

● 能快速学习测试管理工具中附加的先进经验和最佳实践;

● 能有效地进行测试资产的集中管理和控制;

● 能理顺并完善适合本企业内部的测试管理流程，并且映射到测试管理工具中;

● 能促进各个团队进行有效沟通和分工协助;

● 能方便地进行各种数据统计和图表处理，有利于了解项目测试的情况。

在选择测试管理工具时，决策者和相关人员可以根据以上要求来考量测试管理工具是否适合和满足本企业的要求，同时要考量测试管理工具的平台性，即不仅仅只是一个工具，而同时要具有开放性、可扩展性等平台特性，这样才能很好地融入到企业IT建设架构中，真正地成为企业IT建设的基础。

功能和性能测试方面的投资当然是以性能测试为主。原因一方面在于，IT系统的性能问题不易发现，在测试期间只有少量用户使用，往往不会暴露出存在的性能瓶颈，只有上线了以后，千百个分行支行网点的用户使用、并发量大的情况下才会出现，而使用性能测试工具可以模拟这种大批量的用户并发使用。另一方面，性能测试要衡量的指标有很多，依靠工具更加易于进行统计和分析，帮助测试人员发现和定位性能问题。

选择性能测试工具要考量的指标一般有:

● 是否易于创建测试脚本。如通过录制就可以完成，不需要或者需要很少的手工编制;

● 是否能够精确地模拟现实中系统上线后的运行情况;

● 是否能够在压力加载的同时，收集被测系统的资源消耗情况，并且这些数据是真实准确的;

● 是否提供了强大的分析模块和报告生成能力;

● 是否能够和测试管理工具很好地集成。

性能测试工具的价格往往很昂贵，在购买时可以考虑先购买部分功能和模块，然后再分阶段逐步完善。

在自动化功能测试方面，尤其要注意不要盲目地购买，然后仓促地、大范围地在系统功能测试中使用。因为自动化功能测试工具的优点在于通过可重用的脚本和模块，简化脚本创建和维护的工作，同时通过重放，在回归测试中将测试人员从重复性的单调 *** 作中解放出来，使他们更加专注于缺陷修复和功能变更后的模块测试。由于自动化功能测试工具目前大多是通过录制生成脚本，如果以单独一次测试来和人工相比，往往不具有明显的优势。使用自动化功能测试工具能够提高投资回报率的关键在于，通过自动化功能测试工具测试生命力相对持久的系统。例如银行核心业务系统、信贷系统等，通过不断积累和完善该系统的功能测试脚本，可简化该系统变化相对不大的模块的功能测试。

在选择功能测试工具时，需要考虑的最主要指标是工具的简单易用性，因为就实际经验来说，自动化功能测试工具往往由业务人员直接使用，如果 *** 作简单，脚本可维护性好，结果报告清晰明了，那么就会达到事半功倍的效果。

总体上，第一阶段可以考虑优先购买和实施测试管理工具和自动化性能测试工具，同时可以考虑选择一到两个相对修改不会很大的系统来使用自动化功能测试工具录制功能脚本，进行自动化功能测试前期的积累。

逐步建立质量管理体系

如果前一阶段我们的目的是选择测试管理工具和测试工具，同时选择固定的人员，组建相对独立的测试队伍，实现知识共享和经验积累，那么第二阶段我们的目标就是基于本企业内部的情况，制定出适合本企业的质量管理体系，全面控制和管理测试工作，加强功能和性能测试方面的自动化程度，将测试工作和测试团队纳入到整个企业的质量管理工作中，同时可以考虑在本阶段将设计、开发和测试集成起来协同工作。

这一阶段我们应该充分发挥测试管理工具的开放性和集成性，一方面通过它实现与设计、开发、部署等过程良好集成，例如将设计需求快速转变为测试需求，通过测试管理工具管理 单元测试 等; 另一方面可以通过工具提供的功能或者二次开发，建立关键性能指标，从测试管理工具中提取数据，展现测试项目和测试工作的全面视图，例如缺陷的趋势图（每天新增加的缺陷和处理完毕的缺陷）、测试案例计划和执行分析图、测试项目总体进度图等，这样就能通过完善系统质量的衡量指标，逐步建立起质量的评估体系来。

在功能和性能测试方面，由于经过第一个阶段自动化功能测试的积累，已经具有很强的脚本编制和功能组件划分能力，因此可以逐步建立起自动化功能测试的框架，这样做的好处在于: 首先，可以大大简化后期脚本的维护和自动化功能测试的运行; 其次，可以利用框架，快速构建新的系统的自动化功能测试; 再次，可以充分利用业务人员对于业务的熟悉，让他们加入到自动化功能测试过程中来，便于他们使用自动化功能测试工具; 最后，具有一个良好的框架，将来可以快速建立基于业务流程和数据驱动的测试方法，推动回归测试和冒烟测试。

性能测试在这个阶段可以继续深入，一方面通过工具进行针对应用开发代码的性能诊断，协助开发人员发现和定位代码方法级别的性能瓶颈，另一方面要收集各种测试的结果数据，建立起性能和硬件配置的估算模型，充分保证在硬件投资上的最合理支出，提高投资回报率。

该阶段还需要加强的是设计、开发和部署时通过建模工具、配置工具、变更管理工具、运维监控工具、帮助开发人、测试人员和运维人员协同工作，高效率地完成应用系统的整个生命周期中关键环节的管理。由于中小型银行系统主要以外包为主，这里就不做细致的阐述了。

该阶段要注意的是，由于开发以外包为主，所以更需要加大测试方面的投入。因为完善的设计理念、先进的开发技术和方法论、良好的团队合作和项目管理，并不能绝对保证开发出具有优秀功能和性能的应用系统，更何况系统的参数配置对运行的性能影响同样巨大，因此功能和性能是否能够满足业务的需要，最终还是要通过测试来检验。这就好像一个人，虽然具有良好的家庭背景、教育环境、生长氛围，并不一定会成为一个优秀的人才一样，是否有能力能够胜任工作，还是需要通过考试等测评方法来衡量他的综合素质才可以下结论。

促使IT系统和业务目标的统一

银行业IT系统的根本目标是提高生产效率，为银行业务的实现提供强有力的支持。因为银行IT系统本身并不会为银行带来经济收入，收入是依靠其支撑的业务运营来实现的，因此IT系统从设计的那天起，就决定了其要为业务运行服务，要帮助达成业务目标。

但是实际应用开发过程中，由于开发人员过于理想化、开发管理不善等各种问题和各种变化，往往导致最终完成的系统与业务目标具有一定的偏离，这种偏离有时候是很大的，甚至可以称作鸿沟，而IT系统质量管理发展阶段的最终目标就是建立机制，消除这种鸿沟，使IT系统真正能够满足业务目标的需求。

要消除这种鸿沟，可以从以下几个方面考虑:

● 需求和项目管理。这里的需求指的是业务需求，通过项目全生命周期的有效管理，保证应用开发项目的设计、开发和测试都以业务需求为目标，使项目最大化地满足业务需求，实现业务价值。

● 质量保证。通过测试保证应用系统在功能上满足业务需求。

● 性能验证。通过测试验证应用系统在性能上是否满足业务需求。

● 服务水平管理。应用系统上线后，通过实时监控等手段保证应用系统能够满足服务水平协议，使最终用户能够通过应用系统实现业务 *** 作，提高最终用户的满意度。

● 变更生命周期管理。在应用系统整个生命周期中，能够使需求变更被控制在管理范围内，并且能够按照需求的这种变更快速地组织开发、测试和上线后的监控，使这种变更还是依照业务需求进行。

可以看出，需求和项目管理、变更生命周期管理两方面都需要银行内部各部门之间的协助，只有建立起全面的内部质量管理体系和制度才能很好地实现，而质量保证和性能验证就是前阶段的功能测试和性能测试。只有通过测试，才能从功能上和性能上保证应用系统满足业务需求。

这里面要强调一下服务水平管理，虽然目前银行运维部门大多已经具有一系列的工具和手段，可以监控Unix服务器、数据库、网络等底层应用基础架构运行的状况，但是银行是以业务为主导的，最终这些软硬件的运行是要保证业务功能的实现，因此银行监控观念和侧重点应该有一定的转变，即最关键的应该是监控业务功能是否能够正确实现，业务流程是否能够正常流转。举例来说，网上银行系统被不小心修改了登录页面，导致页面出错，这时候传统的监控工具看到的情况是Unix *** 作系统正常、数据库正常、网络正常，但是客户却不能使用网银系统，如果使用了基于业务流程的监控工具，就可以监控到这种错误，并且报警，同时可以帮助运维人员定位到是应用级别出现了错误，从而帮助快速解决这个问题。

选择这类监控工具一方面是要考虑能够有效地模拟真实的用户 *** 作，另一方面是能够将业务流程和底层应用基础架构映射，将业务流程的失效定位到应用基础架构问题。

至此本文介绍了银行IT系统质量管理建设各阶段要考虑的方面，如果我们把银行应用系统比做一个人，那么各阶段的建设可以形象地总结如下:

● 测试先行。就像人定期的健康体检一样，以检查是否有潜在的疾病。

● 全面的质量管理体系。从饮食习惯、作息起居、日常锻炼等方面来提高人的机体的整体免疫力。

● IT管控，消除IT与业务需求的鸿沟。真正明白人生存的价值和意义，不仅仅要有一个健康的体魄，更要从精神、心态等方面来全面调节生理和心理，使自己具有一个乐观、积极的人生。

（作者单位:美科利公司技术顾问）

针对一些企业在IT规划中遭遇的成本控制。比如有些项目在只是一个“名词”，需求还没有明确出来的情况下，就要调研，了解成本，去猜业务部门要做什么。此外，由于业务问题没有约束机制，不论是否真要实施，带来需求满天飞，导致李凡在工作安排上难以平衡。目前李凡也在做一些尝试，通过和业务部门的沟通，将一些成本核算到各个业务部门中，但由于这部分成本占业务部门的比重较低，因此效果并不理想。虽然对于李凡而言，管理层已经接受了IT部门预算执行率不高的情况，但是要求李凡在IT预算和规划中要做的是不能存在漏项。一旦有遗漏，预算的申请将是一件费时费力的事情。其实这种要求，对于李凡所在的高速扩张的行业而言，压力并不轻松

1、不同的行业（或企业），成本费用所占的合理比例区间均有不同，不可硬性作出推断；

2、一般地，应对本企业一段期间的成本费用比例进行比较，结合考核期间的盈利水平以及经营状况进行分析配比，以得出实绩资料，为日后设定成本费用预算提供依据；

3、那么，通过一段时期的实绩对比，逐步推出适用于本企业的经济指标（即成本费用率 等等），从而制定预算，并按照预算开展相关工作；

4、可见，并非一味追求单纯的某项比例，而是应该通过分析来设定合理的适用于自身的数据。

IT预算营收占比是指IT部门在企业总营收中所占比例。IT部门的营收可以通过各种方式获得，包括收费服务、软件销售、硬件销售、网络服务等。IT部门的营收占比可以通过比较企业总营收和IT部门营收来计算。一般来说，IT部门的营收占比越高，企业的经济效益就越高。因此，企业应该加大对IT部门的投资，以提高IT部门的营收占比，从而提高企业的经济效益。

在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。北京IT培训建议是网上找到的一些常规的估算测试工作量的方法：

1、Ad-hoc方法

这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。

这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

2、开发时间的百分比法Percentageofdevelopmenttime。

这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。

通常预留项目的总花费时间的35%给测试。5-7%给组件和集成测试18-20%给系统测试10%给接收测试(或回归测试等)

3、类比法(经验值法或历史数据法)

根据以前或相似项目(主要在项目性质，领域，规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间测试工作的规模，例如用户需求的数量，页面数，功能点数据样式，例如实体，字段的数量屏幕或字段数量测试对象的规模，例如KLOC

4、WBS(workbreakdownstructure)估算法

将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

IT规划就像是一份路线图，旨在引导IT部门走上未来一年甚至更长的道路。但是，对大多数CIO来说，制定一份务实、可行的IT规划却是困难重重。 要是担任联邦快递、通用电气或者瑞士信贷这些大公司的CIO，那感觉肯定很棒――因为在这些公司，IT和业务的关系几乎密不可分; 公司***明白，IT是一项战略资产，因而鼎力支持; 高层鼓励CIO把大部分时间用于考虑大局上。要是在如此美妙的IT环境下工作，起草合理可行的IT战略规划恐怕如同小菜一碟。

但绝大部分CIO所处的工作环境并不好，譬如:业务部门本身无法阐述清楚其战略规划;公司领导不是太关心IT，更不要说在战略上重视IT了; CIO的时间早已被日常运作所占用，哪里还有时间去展望几个月之后的形势。在这样的IT环境，起草合理的IT战略规划几乎是不可能的。

IT规划就像是一份路线图，旨在引导IT部门走上未来一年甚至更长的道路。但是，对大多数CIO来说，制定一份务实的、可行的IT规划却是困难重重。

虽然形势对普通CIO可能不利，但事实上，那些并不掌握战略规划艺术的IT***是干不好工作的。弗雷斯特研究公司副总裁兼调研主任Alex Cullen说: “CIO没有战略规划是不可能成功的，IT战略规划的目的就是促进业务与IT融合，CIO需要用战略规划与业务人员沟通，让对方明白公司的要求以及预期目标。”

美国国家骨髓库CIO Michael Jones将IT规划称为“IT人员的商业方案”。本文将告诉您如何克服起草IT规划时面临的最常见的障碍。

制定哪种业务计划？

IT部门要弄清楚如何让业务部门的愿望得以实现。

制定IT战略的基本准则就是要与业务战略相衔接。独立IT分析师Laurie Orlov说: “业务部门有其希望得到的结果，比如扩大市场份额、提高客户满意度、缩短周期等。IT部门要弄清楚如何让这些结果得以实现。”

当然，业务部门的战略规划通常是更加糟糕的，往往还不如IT部门。Cullen说: “业务部门常常缺乏战略，即便制定了战略，也很粗略、很含糊。或者是他们保留修改战略的权利，或者是战略并不适用于当前的所有业务活动。”

“如果是因为业务部门的战略不够清晰，进而影响CIO制定IT规划。这完全是一种借口。” Orlov说，“CIO绝不能因此而推卸责任。”事实上，模糊的业务目标虽然给CIO带来了挑战，但明智的CIO会把这看成是机会。Gartner Executive Programs公司副总裁兼调研主任Dave Aron说: “业务人员非常关注业务运作或者其他细节，IT人员能够帮助业务部门明确什么会有助于它获得成功、IT可以从中起到什么作用。由此，你就可以从原来的听令行事，变成实际上能影响总体战略的关键人物。”

让机会找上门来

企业如果缺乏雄心勃勃的发展战略，也就无法维系真正的IT战略。

Michael Hites是新墨西哥州立大学（NMSU）CIO,他心里明白，缺乏整体的远景规划将让NMSU面临挑战。Hites解释: “如果你没有落实最高层的计划，IT规划即使制定得再好，也不会成功，对此我深有体会。” Hites在2003年担任CIO时，NMSU的发展计划与其他大学没什么区别。所以，Hites制定的第一份IT规划很标准化，不愿意冒险。IT部门只是埋头把工作做好，但所做的工作却与学校的整体战略无关。Hites认为: “假如你在这种环境下不顾一切地硬来，学校能不能跟上你的步伐还不好说。”

Hites表示，由于学校缺乏比较雄心勃勃的发展战略，也就无法维系真正的IT战略。为此，Hites连续几年向领导层反映，学校缺少发展战略是非常不利的。2007年，Hites被委以重任――负责整个学校的战略规划，还被命名为“规划与技术副总裁”。这种结局让人既惊喜，有欣慰。

Hites和他的团队有很多好点子，他说大约要花1500万美元，但他的部门每年只能得到50万美元的预算。如今，Hites面临的难题是，如何少花钱多办事。

如果大学制定的是“帮助学生成功”或者“加大科研力度”这样的老套战略，那么你做的任何事都会有助于实现这些目标，但问题在于你无法找到重点与核心。“如果学校大胆地表示，我们将在刑事司法领域开设世界上最好的网上教育课程，那么这就成了战略重心。”Hites说。

让IT主导局面

CIO可以帮助企业制定整体的战略规划，而不仅仅是IT规划，这样就从被动变成了主动。

弗雷斯特研究公司副总裁兼首席分析师Bobby Cameron说: “CIO是可以在战略方面帮助推动业务部门的。”而这未必意味着CIO承担第二份专职工作。Kelly Clark加盟Exante金融服务公司（是一家面向医疗行业的金融服务提供商）时，他希望改变IT战略规划流程。

Clark解释: “战略规划通常在年末进行――你看看预算，有多少资金，然后弄清楚可以做哪些事。这很被动。”Clark需要一种主动的流程，“表明这是市场所寻求的，这是我们拥有的资源，这就是我们需要的东西。”

当时，Exante拥有业务路线图制定流程，却没有业务和IT战略，于是他告诉CEO和CFO需要这样一项战略。领导层听从了他的意见。“于是，我们开始动手，制定了企业战略规划，IT就是其中的一部分。”Clark说。

Bethesda Lutheran Homes and Services（BLHS）是为发育障碍人士提供服务的一家教会组织，该组织拥有105年的历史。Brian Tennant担任CIO时，该组织正在实施一个为期5年的战略计划，但这项计划只是名义上有战略性。Tennant回忆说: “计划很宽泛，譬如有很多类似‘最好’、‘快速增长’的词汇，但并没有说明如何进行衡量; 而且，也没有非常在意计划是否正常开展; 一切都脱离了实际。”

坦率地讲，起初这对Tennant来说并不重要。2005年，BLHS收购了总部设在加利福尼亚州的Good Shepherd Communities后，规模扩大了三分之二。“当时，有一大堆现代化项目要做。”Hites回忆，“包括调整核心的ERP系统，IT的使命非常清晰，那就是集成与升级。”

鉴于一切工作都已完成，Tennant认为，该到制定IT规划的时候了，以便引导IT部门顺利度过今后的3～5年。Tennant并没有坐等BLHS组织出台一个全新的、具体的五年计划，具体得足以引导IT部门的工作。相反，Tennant却在帮助BLHS组织制定发展规划。“我认为自己是高级管理团队的成员，只是正好负责IT而已。所以，我抓住了及早参与的机会，参与所有部门，而不是只参与我自己的部门。”Tennant说。

包括Tennant在内的高级主管正与董事会、业务部门、捐赠者和被捐赠者家属一起审查新计划。旨在撰写所谓的“战略定位说明书”，比如吸引更年轻的一代人来捐赠、扩大服务对象、确保财务稳定等。Tennant说: “我已经在考虑IT部门如何帮助实现这些目标。”

从零开始

CIO们都知道需要IT规划，却不知道需要什么样的规划，也不知道希望实现什么目标，或者从何处入手。

KI公司是一家年收入达7亿美元的办公家具制造商，该公司信息服务副总裁Vicki Petit是这样来形容IT战略规划的，“工作量太大了。”Petit毫不犹豫地说。

8年前，Petit担任KI的IT***时面临双重挑战: 公司既没有业务战略，也没有人想过为IT制定战略。弗雷斯特公司的Cullen每年年初都会接到许多CIO打来的电话，其中一半人就是像Petit这样从头做起的人，另一半人是对现有的IT规划不满意。Cullen说: “CIO们都知道需要IT规划，却不知道需要什么样的规划，也不知道希望实现什么目标，或者从何处入手。”

头几年，Petit苦等业务部门的战略计划。但得到的不是计划，而是大部头。她翻阅了KI长达200页的“公司战略书”，却很难找到与IT有关的内容。Petit说:“业务战略主要是以运营目标的形式来体现，很难把IT这一战术与业务战略联系起来。”Petit希望制定一份具体的、长远的IT路线图。

Petit明白，她必须得采取一些实际行动。此后每年，她都会起草IT战略规划，并不断更新; 还根据6个月后的进度给IT部门打分，不断加以完善。如今，她的上司CFO要求所有部门每年都要制定类似的战略计划。

Petit开玩笑说: “他们都喜欢我。结果证明，规划确实很重要。我们可以利用规划来证明IT方向的正确性; 或者否决项目，而不是仅仅被动地满足用户的要求。”

George Lin在战略方面也是从零开始的。2007年4月，Lin成为杜比实验室CIO，他发现落实的IT计划“相当基本”。但Lin所处的环境比Petit好，他得益于非常可靠的业务战略规划流程。杜比实验室对业务战略规划采取了分多个阶段的“漏斗式”方案。公司1000多名员工把所有好点子献上来后，高级管理层通过治理流程对众多点子进行精简，确定当年应该实施的若干项目，以便管理。

Lin打算在IT部门推行类似流程，邀请董事会就战略计划发表高见，并且设立“业务基础设施指导委员会”，负责选择最有希望的项目。Lin说: “我之前在其他公司也是这么做的。IT战略规划流程应与现有的业务战略规划流程结合起来，这样才会得到业务人员的认可。”Lin曾在Advent Software、Documentum和EMC等公司担任过IT领导岗位。

要不然，IT部门就会遭殃。Lin说: “如果IT部门所制定的战略是孤立的，IT人员虽然往项目上投入了很大精力，业务部门却不需要或者不重视这些项目。结果严重挫伤了IT人员的斗志。”

让业务部门参与

IT规划

要是业务部门没有参与进来，即便是非常完备的IT规划也会遭到失败的下场。

2003年，Petit制定了第一项IT战略规划，她很高兴，但她知道该项规划并不理想。于是，她对IT应当关注的重点提出了自己的看法，却基本未听取业务部门的意见。

Orlov提醒: “IT战略规划不可能在真空状态下制定，CIO不能独自想办法。”Petit明白了这点后，一直在努力把IT战略规划与业务目标结合起来，尽管业务目标不怎么完善。Petit承认: “进行这种转变很难。IT规划是向别人展示我们为公司创造价值的惟一手段，所以不能让人觉得我们是关起门来做自己的事。”

Petit认为: “一种比较好的做法是，与职能部门的***合作，听取他们的看法和建议。”

Petit虽未参与业务战略的制定，不过她自有解决办法。“我们制作了利益相关者图表，开始与他们一一会面。我们问对方: 您的衡量标准是什么？您关注哪些因素？由此加强了双向沟通。”与许多人的观点相反，CIO没必要非得“有席位”才能让业务部门参与IT规划。Cullen表示，实际上，让业务部门参与IT战略规划是获得这一席位的重要途径。

Gartner公司的Aron说: “说到制定IT战略规划，绝不能像孩子做作业那样独立完成，这是最大的错误。在制定规划的整个过程中，你一定要让业务部门参与进来。”

Lin在杜比实验室设立了IT/业务联系人岗位，负责听取战略方面的意见。Lin: “不是单单听取高层主管的意见，而是要听取公司上下的意见; 也不是每年编制预算时只搞一次。”今年，IT部门希望为公司设定IT基础设施标准，这是年度计划的一部分。Lin说: “IT部门让业务基础设施指导委员会派人到标准委员会，而不是自己做出决策。”负责审阅战略规划的委员会实际上也参与制定的全过程，这样一来，业务部门就不再是被动地接受。

要是业务部门没有参与进来，即便是非常完备的IT规划也会遭到失败的下场。弗雷斯特公司的Cullen说: “你把规划拿给业务人员，他们点点头说: ‘这计划看上去不错，就这么去做。’但他们心里却在想: ‘为什么要告诉我？我根本没有参与。别找我要钱，因为这与业务需求无关。’”

Cullen举例说，某公司的IT规划中用10页来阐述IT在Web 20方面的目标; 而CFO的烦恼在于，他的E-mail收件箱被限制在100MB。这样一来，CFO显然会对CIO的IT规划摇头，这恐怕也是CIO提交IT规划时最怕见到的一幕。

每年10月，Hites都在新墨西哥州立大学举行年度IT规划大会，与大约100名IT***和学校***进行交流。去年秋季，他们花大量时间探讨Facebook和MySpace对学校有何作用，要不要把课程与这类社交网站集成起来。Hites早在伊利诺斯理工学院时就开过这种大会。Hites说: “之前，我们确实只在IT部门内部进行规划。这样做不仅缺乏成效，而且造成了紧张的局势，被人误以为: 我们希望这样做，而IT部门希望我们那样做。”

让业务部门参与IT规划流程未必要像Hites所做的那么正式。美国国家骨髓库Jones采取的办法是，与利益相关者进行会谈。Jones说: “上至管理班子，下至基层员工，我都与他们交谈。我问他们运作如何？哪些地方正常？哪些地方不正常？”然后，Jones向IT人员问同样的问题，进而证实他所积累的信息; 或者表明哪些地方存在脱节，需要解决。这些会谈帮助Jones把IT计划的内容与业务人员的日常要求结合起来。

Cullen说: “CIO不妨问问同事‘你期望从IT得到什么？’、‘技术有多重要？’如果答案是‘我不知道我需要什么，因为不知道IT部门能做什么’，那么，今年IT规划的重心也许就是: 定义IT的角色。”

Aron说: “要坦诚布公地与业务部门交流，搞清楚IT如何帮助业务部门取得成功。而且，不要担心自己犯错误，犯错不是坏事，它能帮助你成长。”

譬如: 某银行的CIO不妨走到客户服务副总裁面前说: “如果深入了解客户，银行就会成功，因而我们认为，IT应关注注重分析功能的客户关系管理系统。”副总裁可能说: “我不同意你的观点。我认为，只有降低成本，才能赢得客户。”这样一来，CIO心里就有了底，知道围绕哪些方面来制定IT战略规划了。

杜绝借口

IT人员应当用大部分时间考虑IT战略，其余时间的任务应当是确保与业务部门的每项工作步调一致。

做过牙根管治疗的人都知道，这个过程并不好受。但是，如果在制定IT规划和牙根管治疗这两者中选择一个，许多CIO却宁可选择去看牙医。“可想而知，制定IT规划是很痛苦的，但如果停下来认真思考，还是能摆脱被动的局面。”Orlov说，“问题就在于，很多CIO都停不下来。”

弗雷斯特公司的Cameron经常听到这样的抱怨，“我忙于处理日常工作”，“去年我把时间花在了规划上面，但毫无用处”。由于IT越来越复杂，CIO害怕IT规划的情绪越来越严重。Aron说: “眼下，IT方面出现了三种情况: 一是需要发展和创新; 二是由于银根紧缩而继续实行成本核算; 三是IT在公司中的角色不断变化。由于这三种情况相互交织，IT规划会变得非常复杂。”

正如做牙根管治疗，你现在忍痛是为了以后避免受更大的罪。IT规划也是如此。

Orlov说: “战略规划是CIO用来表明IT价值的工具。如果有人对IT的工作提出质疑，它就能成为IT人员的有力武器。所以，你得为此项工作抽出一些时间。”Petit在最近评估IT进度的6个月期间，给她部门打了A，因为以较低成本提供高价值的IT服务; 但又打了D，因为在与产品开发团队一起把技术运用到KI的家具设计方面做得不到位。

“我们当时的目标是在IT部门设立创新小组，而最终却没有设立。我们把大量时间用在了运作上，很少有时间去考虑未来。”Petit说，“这是一种挣扎，你很容易被拖进日常运作的漩涡中，因为人手紧缺。”Petit很难抽出时间来规划，这不足为怪。

为此，Petit把条形图用胶带贴到电脑屏幕上，跟踪自己与其他管理人员会谈、与外部同行交流、会见厂商等方面花了多少时间，与项目或者运作无关的任何时间都算上。目标是达到每个月32小时，占规划所用总时间的20%（Petit是按分钟来跟踪的，总共1920分钟）。Petit说: “在大公司，CIO的角色比较关注战略，职务明确，所以战略规划可能容易得多。而在中小公司，我们得身兼数职。譬如说在瘫痪的网络面前，就顾不上战略规划了，肯定先要搞好网络。”

Exante公司的Kelly表示，即使战略规划很重要，IT部门也要把钱花在刀刃上。“问题常常涉及到钱，大家都在关注资本开支。”Kelly说，我要在人员和流程上确保IT战略规划仍是优先事项。大多数公司没有派专人负责IT战略规划，因而，IT规划就成了大家的负担。为此，Kelly使IT规划成为某位主管的专职责任。

Orlov同意这一观点，他说: “IT人员应当用大部分时间考虑IT战略，其余时间的任务应当是确保与业务部门的每项工作步调一致。”如果IT***（或者其下属）现在能为战略规划留出额外时间，这会成为他们日常工作和交往中的一个有机部分，而不至于很快会被撤掉。IT战略规划也会变得更容易。

所谓“万事开头难”。Cullen说: “如果你在去年第一次进行战略规划，就会发现今年制定IT规划所用的时间比较少; 以此类推，明年所用的时间会更少。这样，你就可以把更多的时间用来与别人探讨和交流，从而减少日常运作方面的时间。”

“这说不定会成为你工作中最喜欢的一部分，因为可以在规划中谈论你想要做的工作、这些工作为什么对公司来说很重要。”这就是IT规划的乐趣。

快速点击

绕过IT规划的四个误区

1．技术在迅速变化，没必要进行规划。

IT顾问Laurie Orlov说: “IT战略规划与过去一样重要。”

“规划从来不会过时。”没错，如果你的战略规划只是单单罗列了几个项目，那显然会遇到麻烦。弗雷斯特研究公司副总裁兼调研主任Alex Cullen说: “要是IT战略规划旨在支持业务，那么它永远不会过时。业务发展步伐越快，它就越重要。”

2．战略规划可以用上5年。

Cullen说: “很多人都将IT战略规划看成是5年的长远规划。5年后，再制定一次规划。”

事实上，不管你的预测水平有多高，你在关注将来5年的情况时，很难准确预测。5年规划带来的另一个问题是，你无法真正熟悉你所制定的IT战略规划，因为十年内才制定两次。

当然，IT规划可以横跨5年，但关注的重点应当是短期; 而且，每年至少要修改两次。Cullen说: “这是一个持续的过程，不是一蹴而就的。”

3．IT预算越少，越不需要战略规划。

每年如何花掉50万美元？又如何确保IT项目是支持业务发展目标的？

新墨西哥州立大学CIO Michael Hites手握50万美元的IT预算，他说: “如果你预算有限、资源有限，又没有战略计划，就不会取得成功。你跟不上技术变化的步伐，因为根本不知道要关注哪些变化。”

4．你无法为IT制定战略规划，因为业务部门没有战略规划。

没有明确的战略（或者没有涵盖所有运营方面的战略），业务部门也能维持运作; 但IT部门却不能。模糊的业务目标会给IT规划带来挑战，但明智的CIO会把这当成机会，帮助业务部门明确其目标。像Hites那样，因此成为了公司的战略师。即使业务部门正在变革中，你仍没有摆脱责任。Orlov说: “业务部门从来不会止步不前，肯定是在不断变化的。但其中有一点是明确的，要是没有IT，有些业务目标是无法实现的。”

快速点击

解读IT战略规划

规划时间: 大多数IT***希望在年初开始考虑IT战略规划，以便吻合预算编制周期。制定IT部门的第一项战略规划可能需要3～12个月的时间。

时间范围: 规划应当横跨3～5年，最应当关注的是接下来的12～18个月，除非有更长远的项目在提交讨论中。

撰写形式: Word文档或者PowerPoint演示文档。制作精简版本，那样万一有人提出问题或者疑问，就可以拿出来。最新颖方法是：如果你供职于分布式或者全球性公司，不妨考虑使用播客。

篇幅长度: 15页或者更短；如果使用PowerPoint，25张幻灯片或者更少。

规划概要: 计划应当先列出针对业务受众的概要。

涉及范围: 高层次目标和规划要针对影响公司业务的各方面的信息技术，而不是仅仅针对基础设施。IT路线图有助于阐明总体战略。

业务环境: 阐明构成IT战略规划的具体的业务驱动因素、业务假设和计划。譬如说，公司正计划收购小公司，那么IT部门的规划就要关注集成技术。

IT原则: 简要说明将指导IT决策和实施的目的。

衡量尺度: 你在制定IT战略规划时要明确衡量进度的尺度，而不是等到评审时，才搞清楚所有衡量尺度。目的并不是让衡量尺度尽量准确，而是能够衡量实现目标过程中的进度。

评审环节: 要对IT规划进行评审，至少每个财年必须修订一次，应当在年初来一次全面评审。

快速点击

IT规划的八宗罪

弗雷斯特研究公司副总裁兼调研主任Alex Cullen见过各色各样的IT规划，有的非常好，有的却非常糟。Cullen说：“大部分规划存在相当多的缺点。应当避免这些错误，确保你的下一项规划不属于糟糕的那一类。”

1．长篇累牍

起草战略规划不是写长篇小说。Gartner公司副总裁Dave Aron说，应当尽量控制在15页内。他见过一份长达250页的IT规划书。

2．束之高阁

最糟糕的IT规划是“起草一次、从来不看”。IT顾问Laurie Orlov说：“战略规划需要有生命力。”为了避免你的规划被束之高阁，就要让曾经帮助起草规划的人参与起来，便于他人查阅，并且常常进行讨论。Aron说：“我知道有一名CIO每次开会都先提到战略。”

3．明年再讲

IT规划需要定期重新验证及更新补充，新墨西哥州立大学CIO Michael Hites每年要对他的IT战略规划更新3次。

4．忽视细节

战略规划同样注重细节。比如说，我们应当在今年使用社交网络工具，以便完成X、Y或者Z等目标，但不应该添加具体的日期或者产品。Cullen说：“人们经常把战略规划变成项目清单。”如果你觉得必须包括业务运营计划，就把它们放到附录部分。

5．一成不变

IT规划不是一成不变的，正所谓：“计划不如变化快。”要预料到意外情况，譬如：要是公司突然进行收购或者领导层发生变化，该怎么办？想要真正改善你的规划吗？那就要增加场景规划或者应急规划。

6．措辞艰深

太多的IT战略规划都是用专门术语写成的。你要明白，你为IT部门设定方向是为了支持业务，所以，要采用业务人员易于明白的措辞。Orlov说：“动不动就提到时髦术语和产品名称的IT人员只是在为IT部门制定IT规划。”

抛掉那些IT术语，把你的目标与关键的业务驱动因素结合起来。

7．一劳永逸

要撰写不同版本的IT规划，以满足规划面向的不同对象（高层管理班子、IT部门、业务部门主管和厂商/合作伙伴）的不同要求，这让人觉得现在要做大量工作，但实际上会为以后节省时间。最起码要撰写特定的介绍或者概要，为同一项战略规划，增加不同的介绍方式。

8．好高骛远

要务实一些。Cullen建议：“你的第一项规划不要把目标定得过高，不要试图什么都想改变。”要是觉得没有把握，就少承诺、多办事。

以上就是关于如何编写IT项目方案.ppt全部的内容，包括:如何编写IT项目方案.ppt、现在企业越来越重视IT了，大家觉得未来企业IT建设的预算投入会集中在哪几个领域呢、银行IT系统的质量控制_银行IT系统等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！