IT现状评估报告IT战略规划项目.doc

下载

下载

40积分

50积分

下载

50积分

VIP价：40积分

IT现状评估报告 IT现状评估报告 IT战略规划项目 版本号： 起草人:中国人寿IT规划项目组 北京市朝阳区建国路112号 中国惠普大厦（100022） 电话：010-65643888 传真：010-65668278 版权说明 本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属中国惠普有限公司咨询与集成事业部所有，受到有关产权及版权法保护。任何个人、机构未经中国惠普有限公司咨询与集成事业部的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。 目 录 121. 概述 2. 业务与IT战略整合评估 13 . 概述 13 . 中国人寿的业务目标和战略 13 . 中国人寿当前的IT目标和战略 14 . 业务策略对IT的要求总结 14 . IT远景，目标以及策略定义 15 . IT举措分类总结 16 . IT战略的总体状况 17 . IT战略对于业务战略的支持程度 17 . IT策略的定义 19 . IT策略的范围对业务策略的覆盖程度 19 . 是否从技术方面都是面向未来发展的 19 . 是否包括企业架构的原则 19 . 是否包括IT治理策略 19 . 业务部门对IT的期望的综述 20 . 决策层期望及IT支持分析 21 . 总公司管理层期望及IT支持分析 22 . 省公司管理层期望及IT支持点分析 25 . IT支持分析总结 29 . 业务与IT整合 31 . 业务和IT沟通流程现状 31 . 业务流程的IT支持现状 33 . 业务和IT关系分析 39 . 业务和IT关系成熟度模型介绍 39 . 业务和IT关系管理(BRM)调查结果 40 . 灵活性分析 44 . 灵活性的概念 44 . 灵活性评估结果 46 . 总结 50 3. 动成长企业模型 51 . 介绍 51 . 动成长企业建设原则 52 . 简易化 52 . 介绍 52 . 中国人寿主要不足 53 . 标准化 53 . 介绍 53 . 中国人寿主要不足 53 . 模块化 54 . 介绍 54 . 中国人寿主要不足 54 . 集成化 54 . 介绍 54 . 中国人寿主要不足 55 . 总结 55 4. 应用架构调研与评估 56 . 应用总体架构现状描述及分析 56 . 现状描述 56 . 应用系统现状简述 56 . 应用的集中模式 57 . 应用间的数据交换 60 . 应用架构 61 . 主要问题 63 . 期望 64 . 核心业务系统 65 . 总公司核心业务系统 65 . 功能描述 65 . 系统架构 66 . 系统评价及主要问题 67 . 江苏核心业务系统 70 . 系统特点 71 . 功能描述 71 . 主要问题 72 . 上海核心业务系统 72 . 系统特点 73 . 主要问题 74 . 深圳核心业务系统 74 . 系统特点 74 . 功能描述 75 . 系统架构 76 . 主要问题 77 . 四个核心业务系统应用技术对比 77 . 建设期望 78 . 财务系统 78 . 现状概述 78 . 功能描述 79 . 系统架构 80 . 主要问题 81 . 建设期望 83 . 再保险系统 83 . 现状概述 83 . 功能描述 84 . 系统架构 84 . 主要问题 85 . 建设期望 85 . 销售支持与渠道 86 . 现状概述 86 . 功能描述 86 . 主要问题 87 . 建设期望 87 . 决策支持系统 89 . 现状概述 89 . 功能描述 90 . 系统架构 90 . 主要问题 92 . 建设期望 92 . 周边系统 93 . 客户服务系统 93 . 现状概述 93 . 功能描述 94 . 主要问题与期望 95 . 代理人管理系统 96 . 现状描述 96 . 功能描述 96 . 主要问题与期望 97 . 精算系统 98 . 现状概述 98 . 功能描述 98 . 主要问题与期望 98 . 电子商务系统 99 . 现状概述 99 . 主要问题与期望 99 . OA系统 100 . 现状概述 100 . 主要问题与期望 100 . 应用架构差距分析 101 . 优势与问题 101 . 优势 101 . 问题 101 . 需求与期望 102 . 初步分析 103 . 应用架构评估总结 104 5. 数据架构调研与评估 106 . 总体数据架构 106 . 现状描述 106 . 数据模型和应用的相关性 108 . 数据物理层次和数据提升（staging） 110 . 差距分析 111 . 用户期望的状况 111 . 差距及原因 112 . 数据标准化管理 113 . 现状描述 113 . 现有数据标准制定和管理制度 113 . 差距分析 114 . 用户期望的状况 114 . 差距及原因 115 . 数据质量管理 116 . 现状描述 116 . 数据质量管理现状 116 . 现有数据质量问题 116 . 差距分析 117 . 用户期望的状况 117 . 差距及原因 117 . 应用系统数据管理 118 . 现状描述 118 . 应用系统数据维护 118  CBPS应用系统数据维护描述： 118  上海应用系统数据维护描述： 119  江苏应用系统数据维护描述 120  深圳应用系统数据维护描述： 121 . 现有数据库平台 122 . 现有数据访问权限控制 124  权限管理状况综述 124  CBPS数据访问权限控制描述： 125  上海系统数据访问权限控制现状描述： 125  江苏系统数据访问权限控制现状描述： 126  深圳系统数据访问权限控制描述 127 . 差距分析 127 . 用户期望的状况 127 . 差距及原因 127 . 数据架构评估总结 128 6. 技术基础架构调研与评估 129 . 技术基础架构总体现状简述 129 . 系统架构 130 . 系统架构现状 130 . 评估分析结果 131 . 业务连续与容灾 137 . 业务连续与容灾现状 137 . 评估分析结果 137 . 信息安全 142 . 信息安全现状 142 . 评估分析结果 143 . 网络架构 148 . 网络架构现状 148 . 网络系统现状 148 . 网络设备情况 148 . 评估分析结果 150 . 系统管理 154 . 系统管理现状 154 . 评估分析结果 156 . 数据中心 159 . 数据中心现状 159 . 评估分析结果 159 . 基础架构评估总结 162 7. IT治理调研与评估 163 . IT治理总体框架 163 . IT治理概念 163 . IT治理的目标 164 . IT治理的架构 164 . IT治理成熟度模型 166 . IT组织架构现状评估 167 . 现状 167 . 组织架构 167 . 职责权限划分 167 . 差距分析 168 . 优势与问题 168 . 需求与期望 168 . 初步分析 168 . IT人力资源现状评估 169 . 现状 169 . 职业发展 169 . 激励机制 170 . 绩效考核 170 . 薪酬体系 170 . 培训体系 170 . 差距分析 172 . 优势与问题 172 . 需求与期望 173 . 初步分析 173 . IT服务管理流程现状评估 173 . 现状 173 . 差距分析 177 . 优势与问题 177 . 需求与期望 178 . 初步分析 179 . 项目管理现状评估 179 . 现状 179 . 一般项目管理 179 . 系统开发 184 . 系统测试 184 . 软件部署 184 . 差距分析 184 . 优势与问题 184 . 需求与期望 185 . 初步分析 186 . 外部资源利用策略现状评估 186 . 现状 186 . 差距分析 187 . 优势与问题 187 . 需求与期望 187 . 初步分析 187 . IT投资成本效益分析 188 . 现状 188 . IT预算与投资流程 188 . IT投资力度 188 . IT成本的构成情况 191 . 效益评估 191 . 差距分析 192 . 优势与问题 192 . 需求与期望 193 . 初步分析 193 . IT治理总体评价 194 . 经验参考 195 . IT治理评估总结 195 8. 附录 196 . 资料：关于数据质量的信息成熟度模型 196 . 资料：Informix向Oracle或DB2的移植 199 . Oracle: 199 . IBM: 200 . 独立第三方报告资料： 200 . 资料 项目管理简介 200 . 资料 IT服务管理（ITSM）简介 202 概述 业务与IT战略整合评估 概述 IT策略必须和业务策略一致，这样才能保证IT有效的支持企业目标的实现，因此IT策略需要建立在业务策略之上，通过分析业务策略找到IT支持点，总结定义相应的IT策略。 麦肯锡已经为中国人寿定义了业务策略以及相关的IT建议，经过高层访谈发现，麦肯锡的报告并没有被作为中国人寿采纳作为其真正的业务策略，而只是作为参考。因此为了尽量保证IT与业务的一致性，在此对麦肯锡定义的IT建议进行描述和分析，同时根据本项目组对于各级业务人员的访谈结果，对IT支持点进行分析总结，为第二阶段的IT策略的定义打下基础。 不过IT策略的制定需要明确的业务目标定义以及实现这些目标的业务关键成功因素（CSF）和这些因素的关键绩效指标（KPI），比如企业的平衡记分卡，以明确IT所支持的对象，帮助在日后在实施IT策略的过程中进行投资回报分析；另外IT策略需要定义在将来一定的时间跨度内阶段性的目标和步骤，这也要和业务的阶段性目标和步骤保持一致，而基于现在获取的业务信息缺乏这方面的参考，这将给第二阶段的工作带来较大的困难。 中国人寿的业务目标和战略 根据麦肯锡报告，中国人寿当前的业务目标以及策略总结如下： 远景目标：在未来6年中中国人寿在寿险/养老/健康险和意外险等所有主要客户群占主导地位的寿险公司，并因此成为中国寿险市场中最能创造价值的企业。 为实现上述远景目标，逐层定义了客户主导，功能卓越以及业绩至上三个的目标，并针对每个目标按照不同的业务领域和职能定义了具体策略。具体参见《实现中国人寿转型，成为以客户为主导的行业领导者》第5章（麦肯锡2003年7月）。 中国人寿当前的IT目标和战略 业务策略对IT的要求总结 在麦肯锡的业务报告中根据业务战略提出了对IT的支持要求，分别按照其3大业务目标总结如下： 总体要求，和业务策略相适应，IT的发展主要定位在销售渠道的支持和客户关系管理上以帮助实现占领主要客户群的业务远景目标：“IT要和业务策略的实施路线保持一致，并且以销售人员/渠道工具和管理信息系统为重点，在过程中利用平台标准化，集中控制，整合数据中心等技术手段。需要开发一个提供客户保单信息以及相应背景信息集成视图的通用数据库从而实现有效的销售管理和客户关系管理系统。” 客户主导，IT的支持要求在两方面进行描述，一是在业务部门针对细分客户群（包括团险和个险）的销售革新需要IT系统的支持，包括提供销售支持工具，改变或者建立销售人员管理系统以适应业务管理办法和流程的变化，建设系统帮助业务扩展已有的，开拓新的销售与服务渠道；二是提供先进的系统支持风险和资产管理，以为保户创造更大的价值。 职能卓越，IT不单要帮助其他业务部门提高关键职能水平，要求包括：为产品开发部门提供“产品引擎”系统；提供风险管理系统帮助提高公司的资产负债，现金流等风险管理水平，保证在可承担风险的基础上为投资人和客户提供最佳回报，开发新系统支持新的前台以及后台核心运营流程。而且IT作为一个关键职能还要对自身进行完善，具体在后面IT远景，目标以及策略章节中描述。 业绩至上，需要IT对于提高财务分析，决策支持和运营报告的能力进行支持，以保证对于中国人寿运行业绩的分析和把握，包括：建立及时有效的财务报告系统，建立精算利润评测系统以及“模型中心”（以精算角度分析产品，公司利润以及资本情况），加强和重建中国人寿的管理信息系统，支持在总公司获取以及分析最底层的各种数据。 IT远景，目标以及策略定义 麦肯锡业务报告在以上要求的基础上，总结了中国人寿IT部门的远景，目标以及实现目标的策略，列举如下： IT远景：将IT建成核心能力，利用IT建立以市场为导向的、低成本高效率的业务流程以及优秀的财务报告、决策支持和运营报告系统。 IT目标：从三个不同的角度阐述了IT的目标以及实现目标所需要做的工作，包括： 目标1：在业务功能方面，保证业务应用程序紧密的支持所有的业务需求。 前端系统：支持重新设计了的销售以及客户服务流程，如面对不同客户群的销售管理以及多渠道的客户支持。 核心运营系统：实现经过重新设计的核心运营流程。 产品系统：支持核心的个险以及团险产品，并定制新的产品，通过参数化的系统支持高速产品开发。 管理信息系统：支持财务报告，决策支持，运营报告以及更好的风险管理。 目标2：从技术角度，在国家级数据中心的支持下，整体结构经过良好设计，保证系统的可伸缩性。 IT系统需要适应业务规模的扩大，包括数量和复杂程度（如多渠道，多产品） IT体系结构分开数据，业务逻辑和前台界面，并且使用EAI技术进行应用间集成。 物理结构保证可伸缩性，将来整合到国家级数据中心。 目标3：从IT组织角度，促进全面的IT效能的进步。 通过良好设计的IT管理流程改善IT治理状况。 高效的IT组织，具有响应业务需求的能力，特别是在总公司。 建立有力，稳定的IT领导团队。 IT举措分类总结 麦肯锡的策略为在每一个定义的IT的八个支持点（参见《中国人寿IT远景目标及战略党委汇总文件》麦肯锡2003年7月），根据业务战略给与IT的要求和IT的目标定义的一些举措，分类描述如下： 分类 举措 总结 应用系统 在各省市推广现有银保试点方案 根据代理人分级模型提供代理人支持工具（如：销售MIS） 完成呼叫中心试点，并将系统推广到各个省份 在核心运营系统实施业务流程再造 对围绕CBPS建立的核心业务系统进行标准化和更换(开发系统支持99年前老保单管理) 为新产品和业务单元设计新系统 根据定义的系统结构实施新产品系统 设计应用系统架构并作出技术选择 根据新架构和新业务需求实施/修改系统（包括新产品，销售、渠道，核心系统） 在上市公司和资产管理公司内建立企业风险管理系统 关注在4类应用系统：渠道支持，核心应用（CBPS，CLAF，AMIS），新产品开发以及风险管理系统，保证对业务运营的IT支持。 数据 将现有数据库迁移到替换数据库 确定用户信息需求，采用SAS制作报告 建立数据仓库，以便在企业一级整合信息 得到及时准确的统计信息和数据，保证决策管理的及时性和准确性。 基础架构 将分公司数据中心整合为35个省级数据中心 将省级数据中心整合为2 -3个全国数据中心 整合基础架构，提高可管理性和运行效率。 IT治理 短期内集中上市公司的IT组织，长期成立独立的IT公司 确定总公司和省公司报告体系、职责、人员和（管理和技术方面的）技能需求。 组织基于业务单元的IT职能／业务单元的活动，设置基于业务单元的客户经理来协调各个业务单元的需求 在总公司、省公司和市分公司实施新的IT管控和管理流程（如：预算和项目投资评估） 对IT组织启用业绩管理指标 实施有效的供应商管理战略 优化IT组织以及IT内部流程，提高对IT绩效评估以及投资回报的分析能力，改善对于业务部门和客户的服务水平。 业务举措 开展业务流程再造项目重新设计前端销售流程。 为在各省实现一体化客户关系管理能力制定方法 开展业务流程再造重新设计核心运营流程（承保、理赔和保单管理） 为资产管理公司的资产管理工作（如：组合管理）安排基础设施 为资产管理公司层面上的相关界面做好一站式处理的准备 在上市公司采用基本风险管理技术，包括资产基础/盈利报告并在系统内实施 采用更先进的综合风险管理（关键的承保风险和投资中心内的运营风险管理）并在系统内实施 建立管理信息和制作运营与财务报告的流程 这些举措实际是业务部门应当采取的举措，在报告中和IT举措混杂在一起进行说明 IT战略的总体状况 本节分为几个方面就麦肯锡的IT战略状况进行分析，发现麦肯锡的IT策略对于其所定义的业务策略具有良好的支持程度，不过在时间和实现阶段上不能保持一致，另外IT策略主要是一些实施举措清单缺乏框架性的概括和归纳，不益于有效的控制和实施。 IT战略对于业务战略的支持程度 麦肯锡制定IT战略的方法为：制定业务战略(分析业务策略对于IT的支持要求（启示）(找到IT支持的要求和当前IT情况的差距（将差距分类）(根据差距的分类定义举措，从范围上IT策略对于业务策略有良好的支持。 不过就业务战略的实施计划和IT战略的实施计划上，包括时间跨度和阶段时间点上没有清晰的联系，如下图： EMBED IT策略的定义 基本符合IT战略定义的最基本要求：即IT战略是在正确的时间，地点提供正确的技术和应用（Gartner对IT战略的定义）；逻辑清晰，由上至下的方式对IT的远景，目标，策略以及实施举措进行描述。 IT策略的范围对业务策略的覆盖程度 覆盖程度较好，在定义IT举措时按照业务的三个目标进行分析,得到IT的关键支持点，之后以这些关键支持点为基础分析中国人寿的IT的当前的基础和差距，最后仍然基于这些关键支持点定义实施的举措。 是否从技术方面都是面向未来发展的 此方面麦肯锡的报告提及不多，并不全面没有在IT整体架构的不同技术层面提供指导，只在以下两点提出了建议 应用：IT策略建议使用3层架构，即界面，逻辑和数据分开。 数据：数据中心整合，为决策支持建立公用数据库 是否包括企业架构的原则 在描述IT战略时从三个不同的层面进行描述：业务功能支持，技术架构，以及IT组织建设，但没有定义一个企业架构的模型从而进行比较完整的描述。 是否包括IT治理策略 IT治理原则需要和公司治理原则保持一致，需要在公司治理的基础上建立IT治理框架，报告并没有给出建议的IT治理框架，而只提到了有关IT治理的一些举措，包括：提到通过运行良好的IT管理流程来促进IT治理，枚举了关键的IT管理流程，并建议了中国人寿将来的IT组织管理模型：地市，省，中央IT之间以及与业务部门间的汇报关系（直接/间接），以及对IT组织内部启用绩效管理指标等；关于IT运营策略，指出“组织基于业务单元的IT职能／业务单元的活动，设置基于业务单元的客户经理来协调各个业务单元的需求”，准备向单独的IT服务公司过渡，并建议了采用按项目进行预算的方式。 业务部门对IT的期望的综述 本节根据省公司以及总公司的访谈结果进行分类总结并以IT的角度做总结分析，结果如下： 决策层期望及IT支持分析 流程/职能 期望以及问题描述 次数 IT支持点，原因分析 IT建议 IT的支持贯穿从销售动机到销售结束的全过程：外部：强大统一的对外服务平台：Call center的逐步完善；区域服务网络的建立网上销售、服务等电子商务相关查询内部：销售行为的支持：提供销售工具、培训资料、演算系统、产品组合方案，让使用者更方便，从高层管理角度：需要及时的信息流动，可靠的信息来源和准确的资料从经营管理角度：需要业务流程管理，契约维护等高效的实务处理系统公务管理：提高办公自动化程度，提高效率，节约成本 3 系统规划的整体考虑，从企业外部到内部，从决策到操作层进行统一规划。 IT建议 人寿需要财务统一核算，现在机构分散，效率低下，而且数据经过逐层上报后很难避免失真；导致重复劳动，而且发生很多口径不一致的情况 2 数据集中 业绩管理 需要能够取得分支机构的业绩信息，对其机构进行考核 分支机构的数据库中缺乏考核相关的数据，没有应用抽取分析考核数据 销售渠道 同意麦肯锡对销售渠道的建议核看法 在制定IT策略时在渠道上需要和麦肯锡的业务战略一致 审计 在保证业务监管的基础上，业务操作要尽量保证灵活性，包括业务处理，客服，销售 授权和灵活相结合，支持业务的变化和发展，从三个方面时间，范围，实现简单 审计 需要加强内部控制监督手段，减少手工报表的工作量，以及人为的因素影响，提高实时性 数据集中，减少报表的中间环节 精算 精算上对于赢利性分析不够，对准备金分析也不够，但可以满足监管部门的要求 向购买的精算软件提供高质量及时的基础数据 风险管理 能够从资产负债平衡以及现金流两个方面及时准确的进行风险管理，现在不能做到很好的预测，而且上市后会更加复杂 保证财务数据的准确性，业务系统数据和财务数据的一致性 财务 需要看到全公司的资金流向 财务系统以记帐为目标，没有考虑到资金流向的问题。 IT建议 IT建设的目的 － 提高核心竞争力：提高经营水平提高工作效率降低运营成本提高决策能力 —作为IT战略定义的参考 IT建议 IT最有效的交付是提供有效的数据支持决策 保证数据质量，将决策数据的要求逐层实施，从而保证数据基础，提供分析以及报表工具 总公司管理层期望及IT支持分析 流程/职能 期望以及问题描述 次数 IT支持点，原因分析 产品开发 缺乏支持产品开发所需的客户，市场以及销售数据 数据定义统一规划，在最基础的系统层面体现最上层的要求，即在业务系统中包含支持产品开发的数据 个险 决策分析得不到基层的数据，现在手工上报，数据不及时，需要掌握客户情况，可以按险种，经济区域等方法分析数据 2 数据分散，数据模型没有考虑到决策的支持要求 个险 数据质量差，不统一。 数据质量没有校验机制，应用系统数据模型独立，数据描述不标准 个险 对于代理人需要考核，有准确的数据反映佣金发放情况 在系统中添加用于考核分析管理的数据，提高性能支持大数据量的统计分析 健康险 保监会要求，健康险需要实现专业化经营：机构专业化产品专业化精算制度专业化独立核算独立核保核赔专门IT系统。IT系统对健康险业务最大的帮助是建立管理式医疗支持系统这种管理不是传统的报销式管理，而是经营服务 没有独立的健康险系统，现在的业务系统包含对健康险的支持 精算 精算没有得到IT部门的良好支持，工作受到限制 提供精算所需的基础数据，保证数据的正确性和及时性，在业务系统中考虑精算的数据要求 渠道 需要能够针对准客户进行市场调研，当前客户分析，销售的业绩进行评估，管理银行和销售的佣金，对渠道进行管理（包括银行，邮政，代理以及经纪公司等），有效的培训。 为渠道建立展业支持系统，在核心业务系统中需要建立渠道关心的数据的获取渠道 渠道 目前与工行已经联合实现即时出单，以后要在代理上走更广泛的路，如网上销售、中介代理出单等 提供能够迅速实施的中介接口 人力资源 员工的培训需要IT的技术支持， 把培训内容迅速地原汁原味地推广下去，同时降低成本 没有相应的应用系统 人力资源 普通的IT员工的培训主要依托业务部门；总体讲培训不到位； 靠个人到社会上学习 没有IT人员的职业计划以及系统的技能提高和培训策略 团险 需要完整的客户资料，包括客户以及准客户信息，需要同业公司在大客户管理上的信息；需要跟踪国有的大型企业的变化；需要目前所管的客户信息，结合行业的分析数据，在全国范围内按照地域进行管理和分析，为决策指导提供支持 没有针对团险客户关系管理系统，数据分散 团险 团险大客户需要得到优质的服务，比如，团险客户应该能够及时，以自助的方式查询到自己在人寿的信息；另外企业客户是跨地域的，需要统一的标准的服务要求 没有团险客户的使用接口，数据分散 团险 团险销售的业绩信息无法进行收集分析，而且薪酬体系需要以此分析作为基础 建立团险营销管理系统，管理团险销售人员 团险 团险需要个性化的管理，在业务操作时应符合团险的个性化要求 业务系统的建设没有考虑团险的业务特点 团险 团险的销售支持需要个性化的服务，提高团险销售的展业以及销售的效率 没有团险销售支持系统 业管 各网点业务独立，客户不能垮网点办理，这样才能发挥人寿网点多的优势 数据没有统一标准；没有集中； 风险管理 需要了解即时保费和营销情况，可以对保单质量进行管理，控制不良保单，现在保单管理。保单的到期等等，是一笔糊涂帐 业务规则进入系统，对于保单的生命周期对保单进行监控 IT建议 IT有十几家开发合作伙伴，如此分散造成开发成本很难控制，导致质量也无法保证，各地购买的机器的品牌型号不一致，不标准，成本很难控制 建立良好的供应商审核以及管理流程和成本控制流程，提高质量降低成本；需要优化采购流程； IT建议 IT的投资和回报没有量化标准 IT部门进行内部核算 IT建议 IT部门需要对业务更深入的了解，业务需求不能很好的形成IT语言，缺少既懂业务又懂IT的人员 2 缺乏业务数据的统一定义，业务流程不标准，IT人员业务技能不足 IT建议 财务数据和业务数据统计不一致，而且需要统计数据的时间点要全国统一 数据分散，应用系统数据模型独立，数据描述不标准 IT建议 根据保鉴会的要求，单证要统一。管理不断变化的单证，单证消耗多少，作废多少等等。 现在系统缺乏对单证的有效管理 IT建议 以前的系统，经常没有通过严格充分的测试，没有测试报告，没有试运行，或试运行太短 IT项目没有规划，不遵守软件开发流程 省公司管理层期望及IT支持点分析 流程/职能 期望以及问题描述 次数 IT支持点，原因分析 业务处理 业务处理应以客户为中心，可以根据客户进行统计分析，向客户提供一站式服务，自助查询服务 14 以客户为线索管理保单，建立统一的系统共享的客户信息库，提供一站式服务的前端系统 决策统计 业务统计没有基础数据，或者即使有基础数据，也不能通过系统的渠道取得，即使得到也严重滞后 14 没有统一的数据定义，IT和业务沟通流程不通畅，IT内部的应用系统没有总体规划，在系统设计时主要考虑处理而不是管理 业务处理 财务业务数据不一致，财务对于业务数据不信任，业务系统对应收应付数据处理不准确，财务和业务系统割裂 12 系统设计没有统一规划，没有公司范围的数据定义参考，对于数据的生命周期管理不足 IT建议 业务数据不准确，导致必须进行人工复核，甚至错误数据在系统中不被发现 12 系统设计缺乏保证数据完整一致的机制，系统只是按照流程处理，没有包含业务规则，需要按照业务规则对数据校验，从而保证数据的一致，准确 业务管理 希望能够管理指标进行监控，考核以及分析，以便实行规章制度和进行良好的管理（包括营业员，坐席，代理人管理） 7 在系统中添加用于考核分析管理的数据，提高性能支持大数据量的统计分析 业务处理 业务系统升级更换以及打补丁不应影响业务的稳定运行，而且现在补丁的质量不能保证功能被按时按质完成 7 应用系统过度分散，开发人员不足，不按照软件工程的方法进行系统开发工作（特别是上线流程），对于业务需求不能充分理解，IT与业务责任不清 业务处理 老业务以及地方险种的保单和客户和新业务同等重要，在服务上不应有差别，包括客服，财务以及精算 7 多个系统同时维护 业务处理 在业务处理时，审计和风险控制要靠人工，需要自动控制 7 在审计和风险控制上自动化 销售支持 销售人员要能够从公司外部连到公司的系统取得展业支持数据，提高销售效率，另外展业需要使用自动化工具以提高服务水平和效率 7 保证安全性的基础上，通过internet为展业提供支持，制作展业支持软件，要统一系统规划定义系统间接口 IT建议 集中采购效率低下，无法满足业务处理的需要，对于采购申请的拒绝没有反馈，而且采购轻视服务的采购导致得不到有效支持 7 改进IT预算和采购流程，提高采购效率。提高集中程度，做好规划 业务处理 不同的部门对于同一名词的数据含义理解不一致，导致混淆出错，系统间数据标准不统一 6 没有统一的数据定义，IT和业务沟通流程不通畅，IT内部的应用系统没有总体规划 IT建议 集中的目的主要是控制风险，但还需要保证效率（客户服务，业务流转时间，物流速度） 6 使用先进的应用技术和基础设施来保证效率 IT建议 总公司对于地方系统出现的问题以及功能扩充反映慢，不能满足地方业务的要求，而且临时任务多，没有计划，总公司的计划只有目标没有实施计划，包括成本，技术可行性分析等。 6 人员不足，缺少问题管理流程；系统设计缺乏地方差异性支持 业务处理 希望得到其他保险公司的黑名单信息，希望得到医院的门诊信息，以及其他政府部门和公司的信息，以降低道德风险，提高服务水平 4 设计系统外部接口方式，和外部系统实现按需互联，交换数据，并且保证安全 业务处理 操作效率低下，响应时间过长。 4 需求中需要有性能指标，在实现时性能作为验收标准 IT建议 IT垂直管理，统一标准是正确的，不过需要对于小的东西适当放权，可以响应本地业务部门提出的需求 4 在集中后也需要建立流程和人员满足本地业务的支持 IT建议 对于业务需求的响应速度慢 4 需求缺乏规划，IT策略和业务策略的一致性 IT建议 总公司的IT人员在省公司实习较短经验不足，没有基层的管理经验 3 需要良好的IT人力资源管理以及职责定位 IT建议 业务人员需要提高应用和电脑的操作水平以提高效率 3 IT部门向业务部门提供应用电脑操作的培训服务，对于应用需要提供完整的操作手册 业务处理 需要能够跟踪保单所处的状态，保证客户服务和管理的需要 2 业务规则进入系统，对于保单的生命周期对保单进行监控 销售渠道 从被动服务到主动服务，增加电子商务、电话销售等服务内容 2 总体规划核心系统，提高灵活性，快速支持渠道的添加 团险 团险的销售员的人数，素质，产能以及骨干力量比例的数据无法得到 2 没有团险销售员管理系统 渠道 银保通在推广时发现对大的交易和数据量支持不好 2 系统需求不完善，对于非功能要求不明确，软件开发管理流程没有被遵守 财务 精算和财务对业务有控制功能，需要通过财务来有效控制业务风险 2 统一规划系统，根据业务规则建立应用系统间的接口 IT建议 IT部门即要完成上级IT部门的任务，又要完成当地业务部门的要求，没有统一协调，工作被动 2 没有定义IT的服务接口和流程，包括对于不同级别，不同地域提出的业务需求的响应流程，而且IT内部的管理流程不清晰， IT建议 IT人员的培训和技能要求不明确，不能通过培训帮助及时有效的完成任务 2 没有清晰的IT发展策略，人员角色和职责定义，以及IT人员职业发展计划 IT建议 业务部门在出现问题和提出需求时，感觉IT责任不清，出口多 2 没有定义IT的服务接口和流程 IT建议 在谈需求时与IT人员沟通困难，IT人员对于业务了解不够 2 缺乏业务数据的统一定义，业务流程不标准，IT人员业务技能不足 IT建议 IT人员权限过大，可以操作和看到关键数据对于业务很危险 2 定义数据标准中包含权限定义，制定安全策略 业务处理 希望保单能够“通存通兑”，异地投保，本地享受服务，增加客户服务质量 全国系统集中或者统一，在不同的核心系统间建立接口 业务处理 不同的险种数据在处理时发生冲突，如意外险和寿险使用相同的保单号导致保单跳号，另外对于健康险支持不好 所有险种的流程支持都是从个险演化而来，没有统一考虑各个险种的系统规划，健康险的业务规则没有建立 业务处理 在处理代理机构的保单功能不准确，加保必须先退保再重新保险造成麻烦和客户损失 在系统建设时没有统一规划，需求的实现靠事件驱动，没有建立良好业务IT需求沟通渠道 业务处理 统扩业务中查询客户信息困难，大客户支持不足，财务数据需要人工合并容易出错 在设计系统时只考虑处理的功能，没有考虑客户以及其他业务部门的要求，需求不完善，使用者没有参与需求 业务处理 业务需求中异常的处理不被支持，如紧急改单的要求，需要灵活，安全的支持业务要求，团险大的保单的支持也不灵活 缺乏规范的系统设计和开发方法，和业务的需求不规范 业务处理 需要自动进行单证管理 应用系统没有单证自动核销功能 精算 关于精算，发现同样的条款，不同的省精算的结果也应不同，如果相同则可能会造成分公司的亏损 数据分散导致处理结果不一致 精算 现在不能分析收益，包括利源分析和利润分析，而且个险团险不分 根据业务需求的精算分析指标开发精算系统 精算 精算数据不准确，需要人工修改 在开发时没有统一考虑精算和核心业务系统 财务 预算需要自动化，现在只有记帐做到了自动化 建立财务预算支持系统 IT支持分析总结 根据上表的分析，按照IT支持的不同层面总结IT对于业务期望的支持点如下： 支持决策分析和管理 在建设应用系统时需要同时考虑决策，管理，业务操作三个层面的要求；将决策和管理所要求的数据逐层实施到各级应用系统，以保证数据基础。 数据集中，减少中间环节，提高统计分析的准确性和及时性。 按需建立统计分析和决策支持系统。 支持业务稳定，高效，安全运行 应用系统中除实现业务操作流程之外，还要实现业务规则，包括数据的合法性校验，对于数据的状态进行监控（如保单状态的监控，代理人考核预警等），提高风险控制能力并保证数据的准确性，一致性。 改变以个人寿险为基础的系统扩展状况，不同险种分别考虑，单独设计，最后整合集成。 建立安全策略，改善应用系统和基础设施提高安全性。 需要新的系统弥补现在IT支持的空白，包括：各个渠道的展业支持，团险销售人员的管理，单证管理，门诊健康险，财务预算，资金流向管理支持，HR的培训支持。 以核心系统为中心，集成内部应用系统，建立工作流机制（包括使用影像系统）提高效率，减少不一致性。 设计统一高效的外部接口，支持渠道的扩展以及外部单位互联的要求。 根据业务量的增长规划基础设施，保证可用性。 提高客户服务质量 建立以客户为主体的业务数据模型（以客户为线索管理保单而不是相反）。 应用系统间共享统一的客户资料库。 提供一站式服务的前端系统。 提供客户自助查询系统，加强对大客户的支持力度。 加强对老业务的支持。 统一系统，支持客户跨地域的服务。 改善IT运营服务质量以及对业务运行的支持力度 IT策略与业务策略保持一致。 建立标准的IT业务的沟通流程，提高IT人员的业务能力，保证需求的质量。 遵守规范的软件工程和软件设计以及开发方法保证应用系统质量。 改进IT内部流程，包括运维，问题管理，供应商管理，采购，预算（采购和预算在总公司统一流程的要求下对于IT执行的部分进行优化）提高运行效率，降低成本，及时响应业务需求。 加强总公司IT部门的建设，响应总公司的业务需求，增强对下级IT部门的管理能力以及计划能力。 上述支持点需要建立在良好的基础之上，总结如下： 建立企业范围的数据标准，包括数据的定义，属性，数据的关系描述，权限要求，数据流以及数据的生命周期，数据的相关业务规则等，以保证数据在业务部门和应用系统间一致。 应用系统的架构总体规划，包括从企业外部至内部，从决策层到到操作层进行统一考虑；现在使用的系统的目的是面向操作和运营，不能适应管理和决策的要求，而且不同的应用系统分别实现，导致应用之间相互割裂，效率低下；总体的应用规划将定义整个中国人寿的应用框架以及建设原则，在应用系统建设时需要明确应用所在的位置以及和框架内其他应用系统之间的关系；在实现时遵守总体架构所规定的建设原则。 规划IT内部组织结构和流程，保证服务质量，降低总拥有成本。 业务与IT整合 业务和IT沟通流程现状 本节概述当前中国人寿IT与业务的沟通情况，从几个不同的角度对业务部门在IT工作流程中的参与程度进行描述，这些描述将作为输入在下面的“业务和IT关系分析”一节中使用。 IT和业务间的报告机制 ：由于上海，江苏等省的业务系统单独实现，因此在报告流程上与其他的省会有轻微的不同，如图所示： IT对业务计划制定过程的参与情况：基本没有参与，但业务部门期望有IT部门的参与，从IT支持和创新的角度提出建议和意见，使得业务部门的计划更加完善和可行。 业务部门对IT投资计划制定过程的参与情况：业务部门在提出可作为IT计划依据的需求前，会就需求和实施意向和IT部门进行沟通，以明确其可行性；IT投资计划的制订是基于业务提出需求，由IT部门总体评估并编制实施计划，经公司决策层批准后确定；对于突发的、紧急的计划外业务需求，IT部门同样有计划外采购流程来进行实施。 应用系统开发中业务部门的参与情况：在应用开发过程中，业务部门主要承担以下两方面的工作：一是需求定义：但缺乏需求定义方法和标准，结果使得需求定义的准确性、全面性都取决于具体的编写人员；二是用户验收：但缺乏完善的用户验收测试(UAT)过程，使得测试不够完善的彻底。 IT采购流程业务部门的参与程度：除了一些职能部门（如财务等）外，业务部门基本不参与IT采购流程。 IT管理在公司发展战略和运营中的角色：从业务部门的角度，普遍认为IT在公司的发展和运营中充当着非常重要的战略合作伙伴和运营支持作用。 业务流程的IT支持现状 本节就IT应用系统对于业务流程的支持能力的现状进行分析，针对IT对于业务流程的支持能力就以下两个方面进行评分： 功能性：业务流程通过IT系统而达到的自动化程度，即所规定的业务流程步骤中实现IT自动化支持的比率。 非功能性：在IT系统帮助业务流程实现或者部分实现了自动化的情况下，这些支持的非功能方面表现；包括稳定性，效率以及灵活性方面的评分。 需要注意的是，IT对于业务流程的覆盖程度是基于业务流程被确切定义的基础之上，只有当业务流程被确切定义后，才能考虑哪些流程中的步骤应该被IT系统所覆盖，而现在中国人寿主要的流程定义体现在保单管理方面（《实务手册》）并根据此流程的定义开发了核心业务系统，另外根据代理人的基本法要求开发了代理人管理系统，其他的流程并没有被确切定义并向IT提出整体要求，如财务预算，团险销售员管理等，因此统一标准评分较难实现，现在使用的方法是，对于有规范的业务流程定义并向IT提出要求的流程，覆盖率为实现的步骤数量与流程要求数量的比例；而对于其他流程则根据业务部门的需求状况和现在IT实现进行比较得出结果，评分的结果用于分析当前IT对业务流程的覆盖程度以及表现，为第二阶段的举措制定打下基础。 由于当前人寿省公司和总公司业务流程不同，而且就省公司而言IT系统的建设也可以分为两类，一类是使用总公司下发的应用系统，另一类是使用自行开发的系统，包括上海，江苏和深圳；因此本节的描述基于三个实体进行包括总公司，使用总公司系统的省（山东），自行研制系统的省（江苏），结果如下各图所示： 注：上述业务流程多数为小流程的合并，业务流程的具体包含的子流程如下表所示，打分在小流程的基础上进行，经过加总平均后得出上述结果： 省公司流程定义 流程 子流程 流程 子流程 产品管理 产品开发定价 销售渠道（中介） 银行 产品部署 邮政 产品属性维护 其他渠道 机场 产品停止销售 保单管理 新契约 精算 效益分析 出单 准备金计算 保全（变更，保单贷款，客户服务） 风险控制 理赔 营销 收展员 收付费 佣金 保单终止 考核 单证管理 架构 风险管理 核保 培训 核赔 销售渠道（团险） 挖掘潜在客户 财务 账务 取得客户需求，定义方案 预算 销售 人力资源 员工档案 客户关系维护 考核 销售渠道（个险） 挖掘潜在客户 培训 取得客户需求，定义方案 工资 销售 决策支持 管理分析，决策支持 客户关系维护 总公司流程定义 流程 子流程 流程 子流程 产品开发 产品开发定价 财务 帐务 产品部署 预算 产品属性维护 采购 产品停止销售 公司管理 战略规划 人力资源 员工档案 企划以及市场 考核 决策支持 管理分析，决策支持 培训 精算 效益分析 工资 责任准备金计算 风险控制管理（功能很弱，没有条件做） 省公司情况总结 在流程的自动化程度上，可以看到在省公司对于涉及到保单处理相关的流程以及代理人管理流程的支持度很高，不过代理人管理缺乏预警的支持，而团险的营销管理几乎没有，主要原因是还没有公布团险销售的“基本法”，对于销售渠道展业的支持很弱（在山东对于个险的展业支持稍好）；另外再保险业务流程基本没有IT支持。而在省公司对于支持类的流程实现的自动化程度不好，财务只实现了基本的记帐功能，没有预算等财务管理方面的支持（不过有些省为此单独开发和购买，如浙江和深圳的固定资产管理软件等）；人力资源系统的支持很弱，虽然部分步骤实现了自动化如员工档案管理，但在非功能的支持能力方面表现的很差基本上在不可用的边缘。 有些流程的支持率高并不表明此业务流程得到了IT的全部支持，而只表明针对业务或者实务流程的要求已经被IT系统所实现，可以看到由于保单管理具有实务流程的定义，个险代理人管理有基本法定义，因此IT可以做到根据业务流程的定义实现基本所有业务步骤的计算机化。但实际上根据访谈发现在实际的处理过程中有一些步骤没有做到计算机处理，如现在对于门诊类健康险的操作不支持，录入数据还需要人工复核等，这需要BPR定义新的业务流程后针对新的流程开发应用系统进行支持。 在IT支持程度（非功能性）上，除人力资源外其他的支持较好，以下为不同的流程支持问题的主要表现： 精算：准备金计算的灵活性较差，表现在当准备金计算周期发生变化时，改造系统造成较大的影响。 核保：效率问题，表现在核保速度慢。 财务记帐：没有和其他系统有效集成，效率不高。 总公司情况总结 在总部的业务流程自动化方面，精算系统已经基本覆盖了当前的使用需求和监管要求，但不能满足更多的分析要求，体现在灵活性不高，效率低下，另外人力资源系统由于使用了外购的软件，对于现有的业务流程有了比较完整的支持，对于以后发展来讲IT应该增加对于培训方式的多元化支持，包括使用视频和互联网的方式进行培训等；产品开发和财务业务流程的自动化程度需要提高，包括产品开发定价以及财务预算管理，现在IT自动化程度最低的部分是决策支持，需要的决策分析数据多以手工报表的形式到达总公司，再进行汇总，准确性和效率都不能保证，对于总部的风险管理，业绩管理等公司管理流程，由于其需要有效及时的数据进行分析，而现在这些数据都没有，更谈不上自动化的支持。 业务和IT关系分析 业务和IT关系成熟度模型介绍 根据行业研究和多年从大型企业级客户认识IT与业务之间关系中获得的经验，惠普形成了一套确定业务 和IT关系成熟模型的架构。该模型帮助分析当前企业的IT成熟程度，并建议采取哪些步骤走向更成熟的阶段。通过将IT与业务之间关系的几个方面的简单分析方法与成熟度模型中的4个阶段相联系，确定在整个发展过程中所处的位置：. 1，确定组织今天处于何处 2，确定帮助自己成功地迈向明天的战略。 根据业务与IT之间关系的有效性，该模型共有四个阶段，每一阶段在发展过程中都建立在前一阶段基础之上，按降序排列四个阶段分别是： 1. 以客户为中心：确定在业界的领导能力，如果实现这一点，必须先实现以业务为中心。 2. 以业务为中心：提供世界级的客户服务，但需要首先完成过渡阶段。 3. 过渡阶段：IT向业务靠近作为在下一阶段建立世界级服务的基础阶段。为了做到这一点，需要解决基础设施问题并释放占用的资源，IT从关注技术转变为关注业务，不过首先要摆脱以技术为中心。 4. 以技术为中心：要走出以技术为中心，需要使基础设施处于控制之中，如果企业中业务与IT职能之间的关系是以技术为中心，那么利用IT支持业务需求的程度就会很有限。 业务和IT关系管理(BRM)调查结果 中国人寿的不同级别的业务人员对BRM问题进行了回答，并根据自己的经验对业务和IT的关系提出了不同的看法。分析结果将有助于为中国人寿沿成熟模型前进指明方向，从而形成中国人寿的IT战略。 对中国人寿的BRM评估： 业务与IT关系成熟度的整体状况 在下面各个图中的每个不同的位置（A－E），都有相应的特点定义，根据当前中国人寿的情况和这些定义进行比较，从而确定中国人寿针对成熟度的不同方面当前所处的位置。 与IT相关的投资决策的实现 观察结果： IT投资决策在相当程度上由IT部门主导： IT项目以及运营的投资都属于IT的成本范围。 业务部门向IT部门提出服务的需求，由IT部门决定是否实施以及如何实施，如果发生冲突则需要上报公司领导，业务部门不会因为IT项目付费。 在实施新技术方面IT的位置 观察结果： IT 根据当前的需求或维持当前运营要求使用新技术： 目的是延长当前所使用技术的寿命，降低风险。 充分利用成熟或使用过的技术，包括 — 实施那些经证明有效以及从前使用过的技术满足运营需求。 — 业务价值从维持当前运营能力中产生(而不是通过从战略或创新角度适应新技术获得价值) 主导的IT服务原则 观察结果： 针对客户现有很少或几乎没有服务 在产生问题时责任不清。 定义了IT服务，但是实践中质量发生变化。 IT制订服务标准。 现在IT使用的技术是成熟的，商业化的技术，IT实现的对业务的支持能力主要体现在维护现有系统正常运行上。 IT的开发方法 观察结果： 项目的优先顺序由IT决定。 绝大多数业务需求是对现有系统的加强。 根据业务部门的需求逐步完成工作（相关需求不能一次提出和实现）。 IT只对业务需求作出反应。 绝大多数开发是集中式的。 在项目定义和开发时，会有一些IT部门与业务部门之间的合作，不过决定权在IT部门。 IT组织的业绩衡量措施(KPI) 观察结果： IT绩效标准由IT部门自己建立并跟踪。 各项措施主要面向IT内部。 除了IT自己跟踪绩效，也会征求业务部门的反馈意见。 对于IT的评估在内部缺乏相应的指标，如停机时间，开发的缺陷数量等，不过定期会取得业务人员对IT的满意度的评价（根据感觉）。 IT业绩与业务结果之间存在何种类型的关系（IT的运行问题导致的业务后果） 观察结果： 没有可以跟踪的IT与业务的关联趋势数据，如IT的停机时间所导致的业务结果。 不过可提供特定的“时间点”数据，如在IT停机发生时可以取得耽误核保的保单数量。 在业务的运行情况和IT的运行情况的数据之间没有进行统计和关联分析。 对中国人寿的BRM评估： 来自总公司业务职能部门的观点 在总公司业务部门进行调研时，由被访谈人在BRM问卷上的问题进行评分，所得的结果进行平均后得到的分数表明业务与IT关系的成熟程度：在很大程度上是“以技术为中心”的，还未完全进入过渡阶段： 观察结果： 被调研的人员一致认为IT的中心仍在相当程度上以技术为中心，而受业务战略的驱动较小，以下是几点主要观察结果： 所有的业务部门都认为IT是他们业务的一种战略资产，IT能够帮助他们更好的开展业务。 IT部门的领导在组织的整体管理方面具有相当重要的战略地位 虽然IT服务还处于运营支持层面，业务对IT服务的质量比较满意。 全体一致认为现有的IT系统并不完善，没有整体规划，系统间割裂没有集成。 在IT项目中业务部门人员的参与程度较少。 对中国人寿的BRM评估： 来自分公司业务部门的观点 省公司的BRM的问卷在BPR组的帮助下挑选了10家分公司进行回答，调研结果如下： 可以看出在分公司的角度上IT与业务的联系更为紧密，IT根据业务部门的需求为业务运行提供支持，表现在多数分公司从业务的角度： 认可IT是公司的战略资产和主要的业务资源。 认为IT的功能的实现是面向业务需要的而不是面向技术需要的。 IT在公司中收到比较高的重视 IT的投资带来了业务运营的高效率。 认为IT是实现企业竞争优势的重要推动因素。 但是，在另外一些方面评价较低，包括： 在IT策略与业务策略的一致性方面的评价比较低，原因包括IT策略以及业务策略的不明确，IT只是被动的响应业务提出的需求。 业务部门在参与IT项目的程度不高。 为最终客户提供服务在IT部门优先级较低。 另外对于现在IT是否能够支持未来业务目标的评价上分公司之间的评价差异较大。 灵活性分析 灵活性的概念 企业如何能够根据客户需求的变化，制订最适当的价格，并及时推出各种产品与服务？ 企业应如何根据自身需求，建立和取消合作关系？ 正如这些问题所暗示的，企业不可能预测到在短期或长期内将要发生的情况。企业必须具备出色的灵活性，并能够动态满足这些挑战，同时还需要能够充分利用当前和未来市场的优势。 由于不能预测到将要发生什么，企业必须制定正确的战略，以使自己能够及时对市场的变化作出响应，甚至有针对性地作出一定的预测。出于这一因素的考虑，灵活性正日渐成为众多企业的一个重要业务基础。一个灵活的企业将能够快速做出以下行动： 了解市场动态，并预测客户需求。 设计、推出或修改产品与服务。 实施系统交付新的商业价值，即使这意味着需要重新修改信息基础设施。 确定内部或外部的资源(人员和产品)。 确定变化的需求，并采取灵活的、建设性的措施。 这些业务压力使得IT部门需要快速跟上市场的变化，同时为企业创造巨大价值。这要求IT部门在降低IT成本和提高投资回报之外的工作。 业界预测显示，业务环境目前变化的速度是IT部门所能支持的速度的7倍。快节奏的变化与可预测性的降低，不仅使得IT能力与业务需求之间的矛盾日显突出，同时还会降低企业响应挑战和抓住新机遇的能力。这就对企业的首席信息官提出了更高的挑战，他们需要将IT能力转变为业务灵活性的真正支柱。 一般而言，IT部门的绩效主要通过其所支持业务流程的成本和稳定程度来衡量。随着业务变化的加快、可预测性的降低、以及对IT部门需求的增加，对于首席信息官和整个IT部门的衡量需要将灵活性涵盖进来。 当面对重要业务变化，如合并或并购时，IT灵活性可能意味着快速的投入运营的能力。当推出一款新产品或一项新的服务时，它可能意味着缩短产品上市时间或提高盈利能力。当进入一个全新业务环境或采用一个新的业务模式时，则需要具有出色的IT基础设施灵活性，以支持这一变化。 灵活性挑战同样适用于小的变化，而这些变化可能会耗费大量的时间和精力。此外，变化也可能无穷无尽。企业及其IT员工面临的灵活性挑战可能会以不同的形式和规模出现。在当前的环境中，唯一不变的只有变化；而要适应变化就需要灵活性。 实现灵活性并不容易，且衡量方式也多种多样。通过与INSEAD(欧洲业务管理协会)的协作，惠普推出了一套工具和流程来帮助企业在以下三个方面衡量和评价其灵活性： 时间：响应变化需要多长时间？ 难度：采取变化需要克服哪些困难(以人力和支出等衡量)？ 范围：哪一范围的变化可以进行有效管理？ 灵活性不是传统IT衡量尺度，包括服务质量、总拥有成本和风险的替代标准。相反，它是这一系列的一个有效补充，因为它是当前所有成功企业的一项必备能力。 灵活性评估结果 灵活性调查问卷从当前保险行业各个业务流程以及职能所面临的变化中，挑选了一些具有代表性的情况（有些是内部的，有些是外部的），针对IT人员进行访谈，让被访谈人对这些变化就以下几类问题进行评分： IT实施此变化所需要的时间 IT实施此变化的难易程度（包括花费的人力和成本） IT实施此变化所能达到的范围（如当佣金结构调整时，是否所有的产品都能够调整） 此变化是否对于企业很重要 基于上述问题给出的答案，使用灵活性评估工具进行处理，得到结果。需要注意的是，此问卷对中国人寿面临现在国际上保险行业所面临的主要变化的反应进行评估，有些变化并不是当前中国人寿所面临的。 灵活性驱动力指数： 灵活性驱动力指数是一个相对值，提供了中国人寿总体灵活性需求的一个近似值。这一指数用1-5之间的数字表示，1代表对业务灵活性的要求较低，5则代表要求较高，这表现在问卷中被调研人认为许多变化情况对企业并不重要。虽然当前的市场环境对中国人寿保险公司的灵活性要求不是很高，但随着市场环境的变化，这一要求也将会逐步提高。诸如对产品生产需求、以及与外部合作伙伴合作的需求的即时响应等领域还比较薄弱。 IT成熟度指数： 基础设施成熟度指数是一个相对值，提供了中国人寿IT基础设施总体成熟度的一个近似值。这一指数用1-5之间的数字表示，1代表成熟度较低，5则代表较高。IT成熟度通过企业对IT部门的支持范围和能力的评价来衡量。评估结果显示企业认为IT部门拥有足够的技术，且运营良好，但在战略方面还存在不足，表现在问卷中关于网络，存储等基础设施方面基本满足变化的需要，但在IT对于业务的变化并没有很好的了解（对于业务变化产生的可能性并不是很明确）。 灵活性总体水平 观察结果 对总体的IT灵活性进行评估，总体灵活性在3个方面均低于平均水平，响应变化的简单性水平最低，这意味着中国人寿保险公司的IT部门估计在应对在问卷中被认可的变化（对于企业比较重要的变化）时，需要耗费大量的资金和精力。灵活性总体水平低于平均线被认为是对面临激烈竞争的企业的一种告警。虽然当前的情况还不足以说明中国人寿保险公司面临着激烈的竞争，但最终市场将会愈来愈激烈，同时客户的要求也会越来越高。 业务流程的IT灵活性支持 对主要业务流程的灵活性水平评估显示，一些流程的灵活性要优于其它流程（下面的第二副图是表现的是根据中国人寿在问卷中对于流程变化的重要性估计以及对业务灵活性的要求和当前中国人寿灵活性状况进行比较的结果）： 观察结果 代理人管理具有比较高的灵活性，表现在能够根据产品以及代理人管理结构的变化进行比较灵活的配置。 在新产品开发，销售支持方面IT做的工作很少，更谈不上对业务变化的支持，而人力资源系统为外购软件，现在能够保证当前的使用，但对于问卷中提到的业务变化基本没有支持。同样对于财务现在只实现了帐务功能，对于其他方面产生的业务方面的变化，IT基本上不能响应。 对于给付和保单管理，此部分实际上是灵活性要求变化最高的地方，IT在这方面表现不好的原因有IT系统本身的原因（如业务规则固化），但主要是业务变化的数量和频率过多导致， 对于合作伙伴，现在的系统只是银保通和银行进行实时连接，系统比较简单，对于以后的类似的外部合作伙伴相连的问题由于只需开发新的接口，因此从容易程度上和响应时间上表现较好，但对于连接新类型的合作伙伴如经纪公司，以及新的支付合作伙伴考虑较少。 对于IT的变化主要体现在IT内部流程的变化以及直接针对客户使用的系统所面临的变化要求，现在中国人寿很少有客户直接操作的应用系统，而且在IT内部流程的调整上的变化也缺少预计，如合作开发模式导致的流程变化的实施等。 从重要性以及业务流程对于灵活性的要求来看，除代理人管理位于优化区域的边缘，其他都位于优化区域之外，因此就中国人寿自身灵活性的要求来讲，现在的IT是远不能满足的。 内部与外部灵活性 内部灵活性反映了IT对内部变化的适应能力，以支持由内部业务结构引起或推动的业务变化。这些变化包括：新的职能要求、流程的显著变化、企业组织结构变化、合并和业务流程重组等。 外部灵活性反映了IT部门响应和适应企业外部变化的能力，这些变化通常由监管机构，合作伙伴以及客户相关业务需求引起(外部变化)。 这些变化包括：满足需要定制产品和服务的业务需求、修改IT基础设施以支持连接新的合作伙伴、客户促销，产品停止销售等。 在问卷中的某些变化的问题来源于内部，有些来源于外部，根据对这些问题的回答归纳如下图： 观察结果 从上图可以看出，中国人寿的内部灵活性要低于外部的灵活性，主要有两方面的原因，一是当前IT很少对于企业外部进行支持，二是IT人员对于企业外部环境的变化也不敏感，导致很多外部的变化情况在人寿看来对其并不重要。调查的结果显示被调查人员对于大多数的内部变化的情况表示认可，而IT对这些变化的响应和适应程度表现较低；如现在中国人寿已经开始业务流程改造项目，而IT系统对于业务流程改造所带来的变化的适应程度预计不高。 总结 麦肯锡的IT战略对于其制定的业务战略的覆盖程度较好且逻辑清晰，但在表述上偏向于响应业务发展的IT措施的罗列，缺乏总体规划，可操作和控制性不强。从不同的角度观察当前IT对业务的支持能力以及与业务的关系发现，现在IT对于业务的支持以当前的业务运营为主，对于管理和决策以及将来的业务变化支持不够，缺乏灵活性，IT系统缺乏整体规划，IT部门的内部流程也缺乏规范化，提供服务的效率和质量较低，虽然业务部门对于IT的地位和IT人员的工作表示认可，在IT与业务关系的成熟度方面中国人寿还是处于较低的水平（基本保持在以技术为中心的位置）IT与业务人员协作缺乏渠道，沟通合作存在障碍。 动成长企业模型 介绍 当前的业务环境瞬息万变，且充满复杂性和挑战性，这使得技术人员需要寻求各种可互操作的技术，并构建一个能够支持不断变化的业务需求的IT环境。然而，目前大多数IT环境均缺乏满足快速变化的业务需求所需的出色适应性和迅捷响应能力。当前的挑战包括： 在优化和降低运营成本的同时，保持优质服务。 利用现有投资，构建一个可满足未来需求的IT环境。 支持快速部署全新解决方案，同时最大限度地提高投资回报和降低风险。 企业越来越依赖IT环境来支持各种变化。一个灵活的企业将能够从容应对这些挑战。为了实现业务灵活性，IT需要能够适应业务和IT环境的变化。 惠普通过将IT与业务紧密结合起来的动成长企业方案解决这些挑战，从而帮助企业可以预测并应对新的市场需求，同时创造并及时把握住新的商机。动成长企业方案的优势在于： 通过构建灵活性战略基础，满足当前的技术需求，进而降低复杂性。 帮助找出并消除利用率较低的资源，整合IT环境，以及提高安全性和可用性。 确保购买的技术能够带来切实的业务优势，为企业提供高技术投资回报。   用于实现动成长企业以获得持久业务灵活性的基础架构框架，被称为惠普达尔文框架。其主要组件包括： 业务和IT环境间的直接的交互循环 规范的信息保证业务流程和应用服务相互独立，并且用于支持创业务分析。 应用系统是SOA（面向服务的体系架构）的一部分，用来支持业务流程运行。 IT服务的管理和控制，以支持业务目标和策略。 虚拟化所拥有的基础设施，共享服务和资源，以及按需扩充基础设施资源和服务。 上述模型最重要和独特的地方在于将业务和IT同步。这对于任何基础架构均非常重要，同步的目标是能够把业务和IT环境无缝连接起来。 动成长企业建设原则 惠普动成长企业实施方案的特色是四项基本适应性的设计原则，用以规定一整套的解决方案、服务和技术组合，以下就这四个原则以及就这四个原则下的中国人寿的主要不足进行描述。 简易化 介绍 简易化的应用和系统更易于使用、连接、管理和修改。资源要求较少的简易化体系结构更易于改变并为实施提供灵活性。 实现简易化的一种方式是进行整合，即确定未充分利用的、性能差的和部署过多的资源并对其进行精简，形成一个改进的基础设施。这是一个包含更少部件的基础设施，更易于管理，并在变化发生时更快、更轻松地做出响应。 简易化可以提供多种好处。例如，除了降低管理复杂性之外，通过减少服务器数量还可以缩短备份和恢复的时间。在进行紧急恢复时，更快地恢复可缩短停机时间。 中国人寿主要不足 中国人寿现在的应用系统比较复杂，增加了使用，管理和维护的难度，以某省呼叫中心为例核心系统分布在各个地市，这样坐席在操作时不单要操作呼叫中心的界面，而且还要操作连接到各个地市业务系统的界面，如果有13个地市，则需要操作14个界面，而当新老业务分开后导致坐席操作的界面数增加到27个，降低了效率，提高了出错率。 在基础设施方面，多种型号和品牌的服务器以及存储分布在各个地市，有些省已经做了物理集中，即将服务器由地市集中到省机房，现在IT人员需要维护和管理每一台服务器，疲于应付，很难做到高效，高质量的管理。 标准化 介绍 采用统一标准可将简易化扩展到多厂商、多操作系统解决方案，促进了流程和数据模型的重复使用，使之具有满足其它应用需求的适应性，而且标准化简化了IT资产部署和使用的环境。IT基础设施的标准化可通过以下几个途径得以实现： 使用工业标准接口、平台和软件开发技术。 建立通用流程和政策以管理变更。 使用商品化的应用软件、技术和部件。 中国人寿主要不足 标准化是当前人寿比较薄弱的地方，体现在各个应用系统之间的数据定义互不相同，数据模型各自为政，应用间接口和数据交换没有标准，不规范。标准化的不足更严重的表现在流程和方法的不规范，不标准，例如：欠缺需求硬件设备的统一指标和方法，缺乏规范标准的开发方法和流程，安全策略的制定方法，问题管理流程，绩效考核指标等。 模块化 介绍 使系统某一方面的变化不会影响其它部件，针对硬件配置、业务需求以及按需服务的要求，模块化能够提高灵活性。借助模块化，可动态增减和重新部署存储和计算能力，以满足各个应用增加或减少的处理需求。在设计基础设施体系结构时，模块化可通过几种方式实现： 系统可以根据业务需求等进行分类 系统可以构建成能够以接近实时的方式连接或断开连接 无需改变其它部分即可修改任何群组、配置或组件 可以轻松地外包IT功能 在当今努力实现完全连接性和互操作性的环境中，模块化有助于大大缩短集成或分离业务系统所需的时间。 中国人寿主要不足 在应用系统方面虽然是根据业务需求，按功能分模块进行设计，但模块间的干涉较多，如一部分程序的修改导致其他程序出现问题，原因即包括没有规范的开发流程，也有在模块化设计上的不足。 基础设施上，服务器和存储设备间相互独立，大多是计算机直连，SAN的程度不够，缺乏资源共享的条件和基础，不能根据业务要求按需提供资源。 集成化 介绍 如系统由多个模块组成，这些模块必须进行完善的集成，以高效发挥功能。集成借助一种易于掌握、管理和修改的统一关系体系，显著增强变更的易行性和范围。如果IT基础设施的各个复杂部分之间的连接不佳，且业务系统和应用仍保持各自为政，要想进行移动、重新配置或重新设计往往会变得十分困难，可能会导致昂贵的定制互联方案。集成将使对基础设施进行全盘管理成为可能。 中国人寿主要不足 应用系统间的集成不足，问题体现在应用之间缺乏数据共享，或者共享不能保持及时性，一致性和准确性，如，统括系统的数据需要人工处理才能进入财务系统，呼叫中心使用的是前一天的数据，统计分析得不到数据或者数据不准确等。 总结 在总体上看，中国人寿并没有一种综合且明确的企业架构框架。同时，企业架构也没有在业务、信息、应用和基础设施方面实现全方位的整合。而且，没有明确的衡量IT对业务影响的具体标准。 应用架构调研与评估 应用总体架构现状描述及分析 现状描述 应用系统现状简述 中国人寿的现有应用系统主要包括： 业务运营类： 核心业务系统，包括CBPS1－7个版本和CBPS投连万能版 统括业务处理系统 银行实时出单系统 代理人管理系统 销售支持系统 客户服务中心系统 业务管理类： 财务系统 精算处理系统 通用统计系统 支持类： 办公自动化系统 中国人寿保险公司信息系统的应用状况是同公司寿险业务发展状况相适应的，体现在：应用系统随着产品的推出而发展，同时，其系统功能和系统结构也在产品营销的发展中完善和成熟。 下表为信息技术部2003年度系统升级工作计划。数据来源于中国人寿《应用系统介绍（尽职调查）》。表中数据表明，首先，现有业务处理系统功能升级开发工作面临较大业务发展压力，应用开发的时间极为紧凑。其次，开发设计涉及的业务范围很大，系统需要补充开发的功能较多。 应用系统 版本 主要目标 开发计划 代理人系统 开发将基于AMIS省级集中的需要，在满足业务指标需求、数据交换需求、信息保密需求、数据分发需求、个人代理人代码升位需求、考核预警功能需求、性能需求、并行需求和用户界面友好性需求等 第一期计划在2003年6月底能提供一个支持集中处理的可运行系统。第二期计划在2003年10月底完成系统的完全改造。 财务系统 根据财务系统现状和系统即将面对的数据集中带来的问题，对原有财务系统改造包括两个部分：加强并发处理能力和优化操作界面、增强打印功能、改善系统结构等。 计划于2003年3月~5月完成系统详细设计，系统编码工作及测试工作 CBPS健康险功能 　 根据目前职工补充医疗保险业务发展和管理的需要，为满足一些重点需求，在CBPS增加处理该应急业务需求的功能，以满足业务管理和信息系统处理的需要。 计划于2003年4月启动此项工作，争取在一个月时间完成此项工作。 CBPS升级 采用中间件技术，进行CBPS的三层改造，解决省级数据集中大并发用户数带来资源竞争而造成的系统效率降低等问题；满足分公司的业务需求，统一公司核心业务系统；完善系统影像、出单系统、团体健康险等处理功能。 2003年3月至4月确定需求，形成需求规格说明，完成系统设计，2003年5月至6月编码测试和业务管理部验收。 完善中介处理系统 　 包括单证核销（银行方面）、与CBPS的接口、财务处理等，包括与邮政储汇局中介系统的接口问题；将系统开发成支持多险种的业务处理中介平台，主要是免核保的险种处理，并成为外部系统和国寿业务处理系统进行交易的中介业务处理平台。 预计2003年4至5月进行需求整理、概要设计，2003年6至8月进行详细设计，2003年8月至12月进行编码和测试工作。 我们对保险应用架构中的10个主要应用进行了详细的应用功能分解，并在35个省对应用功能进行了数据调研。根据调研数据分析，结合我们在总公司IT部门和业务部门，以及8个分公司的访谈资料，中国人寿保险公司信息系统的系统功能能够涵盖保险业务处理的主要方面。 中国人寿保险公司的应用系统和它的主要系统功能的现状为： 应用系统基本能够支持目前的业务运营。 企业变革和业务发展正对信息系统提出不少结构和功能方面的迫切要求。 应用系统仍处于为应对日常业务需求而进行的系统功能和结构完善修改。 应用的集中模式 中国人寿目前主要业务运营类和业务管理类的应用系统是分布部署在分公司，按中国人寿保险公司工作计划，今年应实现省分公司数据集中。 从业务运营方式分析，中国人寿应用集中主要存在以下几种模式： 系统设备物理集中，数据物理集中，业务处理分布。 目前，此类业务集中模式是大多数省分公司主要采取得形式。其主要特点为：建立了以省为主的IT运营支持中心；整合各地市业务数据，建立完整集中的省辖数据中心。 系统设备物理集中，数据物理集中，业务集中，处理流程整合。 在中国人寿部分分公司如广西等，为改善业务质量，提升管理效率，在实现上述省区系统集中和建立数据中心的基础上，对省市业务部门设置和业务处理流程进行了集中和整合。 业务集中流程整合的特点是：变革了省区内业务资源配置，提升了契约、核保、保全、理赔等关键岗位的业务管理质量；整体上减少了业务管理环节，缩短了业务管理决策部署和一线业务营销处理之间的距离；加强了业务管理层对市场和公司管理状况的准确了解。 中国人寿保险公司目前业务集中的基本情况为： 以建立省级IT运营中心和数据中心为主的集中工作将在2003年底基本完成，主要应用系统如CBPS业务系统、财务系统也将随之实现应用的物理集中。 适应省级应用集中要求的应用数据整合，以及支持应用集中的系统功能完善如财务升级开发已开始实施。 目前集中的主要工作由IT部门组织，业务管理部门参与程度较低，同时，配套的业务组织规和业务处理流程欠缺。 未来企业业务集中和整合的目标不清晰。 应用间的数据交换 中国人寿保险公司应用系统之间的数据交换有自动数据交换和通过非自动形式进行抽取、汇总、统计的数据交换，主要数据交换类型包括： 核心业务应用之间数据共享和交换： 如代理人管理系统AMIS同CBPS业务系统之间的数据交换，销售支持系统同CBPS业务系统之间的数据交换等。 业务系统、财务系统等企业内部应用系统之间数据交换： 如CBPS业务系统同财务系统之间的数据交换，CBPS和再保险系统之间的数据交换，客户服务系统和业务系统之间的数据交换等。 企业内部应用系统同银行、邮政等渠道之间业务处理信息之间的数据交换。 中国人寿保险公司应用间数据交换的现状为： 信息系统目前能够支持业务处理和管理上对应用间数据交换的要求。 应用间数据交换主要是针对特定业务要求进行的专门开发；一个系统会存在多个数据交换接口。 应用间数据交换的规范性、准确性和实时性还难以满足企业管理决策的要求。 应用架构 如上所述，中国人寿应用系统的建立主要是同中国保险行业产品和市场发展历程相适应并仍处于发展完善中；因此，应用系统体系是在各个时期业务应用功能的基础上逐步建立起来的。 中国人寿应用架构的基本情况是： 应用架构中的主要业务应用模块已经基本建立。 应用架构的总体设计不足，处于随时完善修改的过程中。 系统架构的层次性和系统功能的模块化不足。 数据、接口等方面标准化不足。 主要问题 总体上看，中国人寿保险公司信息系统的应用架构正处于初步建立和完善发展之中，因此，应用架构存在一些比较明显的问题： 应用架构缺少总体规划，缺少同业务前瞻性规划的沟通，系统业务处理功能、服务功能等总是反复修改，总体结构复杂。 总体结构设计欠缺，层次结构差，系统效率低，维护复杂。 应用系统之间缺少规范的集成设计，系统外挂接口多，应用效率低，数据一致性差。 技术应用滞后，开发语言陈旧（很多开发技术仍采用Informix平台），风险大。 缺少规范的设计管理，缺少规范的技术转移要求，使得中国人寿在系统上难以完全掌 握，存在对开发商严重的依赖性。 中国人寿业务部门对应用总体状况评价 中国人寿IT部门对应用总体状况评价 期望 通过对中国人寿保险公司应用架构状况的调查，根据对总公司主要领导访谈内容的理解，结合对总公司信息技术部负责人、总公司业务部门负责人、分公司负责人及技术业务部门负责人等访谈，中国人寿保险公司应用架构的主要期望包括： 应用架构能够实现及时快速地适应新产品新业务发展的要求。 应用架构能够提供有效地营销拓展支持。 应用架构能够适应销售渠道快速发展的要求。 应用架构能够满足管理上及时准确把握业务状况的要求。 应用架构技术上结构上具有先进性，性能稳定，操作可靠，便于管理和操作维护。 核心业务系统 中国人寿总公司的核心业务系统（CBPS）从1997投入使用开始，一直支持着人寿的业务运行。虽然这个系统有着很多的缺欠，但是，至今CBPS能够基本满足业务运营的需求。 CBPS使用近6年来，在各省的应用中也遇到各种各样的问题，同时，也因为保险市场的不断发展，CBPS通过频繁的升级、补丁来适应业务的需求。但是，尽管如此，CBPS还是存在一些对地方特点难以支持的情况，对此，各地开发了很多的外挂系统，而上海，江苏，深圳则是开发了自己的核心业务系统。 所以，中国人寿核心业务系统的现状是： 存在总公司，上海，江苏，深圳四个版本； 使用总公司系统的各省还在使用很多自行开发的外挂系统功能。 总公司核心业务系统 功能描述 总公司的核心业务系统从1997年12月推出第一版，至今近6年，较大的升级版本有八个，小的升级、补丁非常多，平均每年有10次以上，甚至多达二、三十次的版本修改。 目前，CBPS包含如下子系统：individual and group 客户管理子系统――包括开户、审核、归并和客户资料管理等 新契约子系统――包括投保登记、接单、核保、医务核保的和出单等。 收付费管理子系统 核保子系统 打印管理子系统 综合查询子系统 保全子系统――包括批改、复效、终止合同、撤单、挂失、迁出和生存金/年金给付等。 理赔子系统――包括理赔申请、审核等。  统计子系统 业务控制子系统――包括订正、黑名单管理等。 营销员管理子系统――包括机构管理、营销员管理、佣金计算和统计等。 系统管理子系统――包括用户授权管理和基本数据管理。 权限管理子系统 手工老保单管理子系统 银行转帐管理子系统 支票管理子系统 单证管理子系统 险种定义子系统 银行代收子系统 系统架构 总公司的CBPS系统是以险种为中心的处理系统，在系统的部署上，以地市为处理中心，相应的业务数据也分布在各地市，目前，部分省（15个省）实现了省级的集中处理。 总公司的核心业务系统是终端结构和Client/Server两层结构，开发语言是4GL/EC，数据库平台是Informix，系统硬件平台是小型机和PC服务器。从系统结构方面看，终端结构和C/S结构不够灵活，技术比较落后，难以满足中国人寿快速发展的业务需求。 CBPS与其它应用系统的数据接口有： 从分散于各地市的CBPS抽取业务信息，形成全省的业务信息库，供CALL center、综合查询系统使用。省业务信息库数据再上传总公司，供总公司的查询系统使用。 CBPS接收AMIS系统的代理人/机构数据。 CBPS将保单的部分数据传送给AMIS。 CBPS将收付费信息传送给CLAF。 精算系统抽取CBPS中的保费数据 。 银保通与CBPS交换保单/客户数据。 系统评价及主要问题 业务部门对核心业务系统的总体评价： IT部门对核心业务系统的整体评价： 主要结论如下： CBPS能够支持目前人寿日常业务运行。 CBPS是以险种为中心的处理系统，难以做到以客户为中心，难以适应客户中心的业务需求，比如以客户为中心险种组合，服务组合的要求。 15个省实现省级集中，其余的部署在地市，系统部署过于分散，不利于管理。 终端结构、C/S结构不够灵活，技术比较落后。 系统不够灵活，不能满足各地不同的业务特点，各地因此自行开发了很多外挂系统，甚至开发自己的核心业务系统。 数据的一致性和完整性不好，系统中有垃圾数据。 系统升级频繁，各省维护工作比较重，而且，升级经常会带来新的BUG和产生垃圾数据（系统升级对之前的部分数据不进行相应处理）。 系统的知识转移不够，造成系统故障时定位困难，技术上依赖于开发商。 子系统的划分不合理。 应用系统可以支持固定的产品配置，而对灵活的产品配置支持不足。 对投资产品的管理功能支持有限。 对健康险和医疗险支持有限。 CBPS为了支持目前的业务运营，包括的子系统从业务处理、接口到查询、统计。这样，势必造成核心业务系统过于庞大，结构复杂，难于管理和维护。而系统过于庞大时，很多功能虽然有，但是很难做到灵活、实用。 如统计子系统，存在与CBPS中，它与业务运行没有直接的关系，作为统计分析系统，该子系统提供的功能又不能完全满足统计分析的需要，而该子系统在CBPS中的运行，又会影响到CBPS的性能，这样的子系统的存在是因为整体应用系统缺乏规划造成的，是不合理的。 系统满足业务的程度一般。 问卷调查的结果表明，CBPS满足目前业务运行的程度一般，具体数据如下： CBPS子系统 能够很好的满足业务需要 满足业务需要程度一般或者很弱 产品管理 30％ 70％ 客户管理 19％ 81％ 机构权限管理 35％ 65% 团体新契约 24％ 76% 个人新契约 34％ 66% 保全 ％ ％ 理赔 % ％ 收付费 29% 71% 业务员管理 21% 79% 单证管理 5% 95% 统计报表、信息查询 % ％ 从以上统计可以看出，大部分子系统只是能够一般性的满足业务需要，特别是客户管理、保全、理赔、单证管理、统计查询，对业务支持的满意度在20％以下，是非常需要改进甚至重新规划的子系统。 统计查询子系统功能与业务需要差距较大（满意度%），再次证明上面提到的问题，即，该子系统不适合包含于核心业务系统中。 系统的易用性不好。 调查结果表明，CBPS的易用性不好。具体数据如下： 子系统 易用性较好 易用性一般或较差 产品管理 40% 60% 客户管理 37% 63% 机构权限管理 45% 55% 团体新契约 32% 68% 个人新契约 37% 63% 保全 % ％ 理赔 16% 84% 收付费 37% 63% 业务员管理 24% 76% 渠道管理 34% 66% 单证管理 6% 94% 统计报表、信息查询 18% 82% 从上面的数据可以看出，大部分子系统的易用性一般或者较差。特别是保全、理赔、单证管理、统计查询，而这些子系统却是业务运行核心中的核心，这些子系统的易用性不好，直接影响业务操作的效率。 目前的CBPS与其它应用系统交换数据方面的结论是： 没有统一的、规范的接口，没有数据交换标准。 应用间是按照约定的方式定期进行数据交换的。数据的实时性较差。 业务和财务数据不一致，需要分别检验和核对。 江苏核心业务系统 江苏的核心业务系统实际上是一套综合业务处理系统。1997年，江苏省初步建立了较为完善的信息管理平台，所有营销险种上机处理，为江苏寿险业电子化建设打下良好的基础；2000年，江苏省又提出了寿险财务业务一体化处理的思路，进一步理清寿险管理思路；2001年，按照总公司实务，江苏省对核心业务系统进行改造；2002年，江苏省相继开发了影像系统、红利派发、一站式服务系统。 系统特点 新老险种、个险、团险、短险均统一在核心业务系统中。 支持业务财务一体化，即其业务处理同步反应业务、财务信息，体现业务与财务之间的相互制约关系，对权责发生制记账方式提供良好的支持。 个人代理管理和佣金计算统一在业务处理系统中完成。 支持“一站式”服务，同时支持理赔服务免填单。 支持对机构（如核算单位，业务单位，营业点等）进行统计。 可以实现单位间代收代付的清算工作。 功能描述 江苏省的综合业务系统功能模块包括两个部分，即寿险业务处理部分和寿险业务数据管理部分，见下图。 主要问题 系统功能不够全面。 系统零散，信息数据一致性不够强。 采用的技术相对比较陈旧。 理赔流程需要进一步简化，人机操作界面尽量简单和标准化。 对于业务员管理，绩效分析和业务动态分析需提供更加友好的界面。 上海核心业务系统 上海核心业务系统于2000年正式启用，该系统采用三层构架的开发模式，将各业务模块集中在一起。上海核心业务系统的功能模块包括：产品管理；客户管理；机构权限管理；团体新契约；个人新契约；保全；理赔；收付费；业务员管理；渠道管理；单证管理；影像（接口）；统计报表、信息查询和再保险（接口）等，其组织结构图如下图。 目前，短险系统采用总公司的CBPS，上海分公司核心业务系统很好的支持以客户为中心（见下图）： 系统特点 与影像处理紧密联系，减少保单人工流转带来的差错，实现客户化的档案管理。 对核保处理的支持：动态定义分级核保员的核保额度，可以满足不同规模的处理能力。 支持同一客户多种联系方式的需求。 可接收不同渠道的授权申请；一次授权，可支持各类业务的扣付款和灵活定义扣付款数据的组合方式。 动态定义账户类型，支持不同客户账户管理的需要。 支持一次报案同时处理所有相关保单。 使用工作流机制，有效降低业务处理的成本。 主要问题 数据库安全受到威胁。 网络、数据库负载重，运行压力大。 应用系统模块太多，系统维护、升级工作量大，每次系统升级工作庞大，重复无意义的工作。 各模块定位不准，对操作及维护人员不利。 保全应该提供反操作的功能。 理赔系统手工处理太多，有待完善。 深圳核心业务系统 1998年至2003年3月，深圳分公司采用life98业务处理系统；从2003年3月1日起，开始采用全新开发的LifePro核心业务处理系统。 系统特点 基于产品管理及定义平台的全自动业务计算 所有保险产品通过一个统一的参数化的产品管理及定义子系统进行集中实现，并对外提供关于产品属性、产品规则及产品计算的统一服务接口。基于此，投保业务的费率计算和投保资格检查、保全业务的各种财务变更计算、理赔业务的预赔金额、赔款金额计算等通过产品管理及定义子系统的统一计算服务接口全部实现了全自动计算。另外，还针对CallCenter需要提供了一套投保及保全业务的业务测算功能，大大方便并提高了CallCenter业务员的作业效率和质量。 以客户为中心的服务及风险管理 通过独立的客户管理子系统实现对客户自然状况、健康状况、家庭病史等资料的集中、统一管理，并以此为基础实现所有客户投保风险的分类合计管理，有效监控客户风险状况。 基于工作流思想的业务流程、岗位及权限管理 针对每个工作岗位设置一个业务状态和作业任务池，业务流程通过这些岗位状态之间的业务转换体现。对于承担业务作业的每个部门及其操作员，可以针对其承担的作业岗位分别设置作业权限，权限分三类，一是功能权限，限定作业人员能够使用哪些业务功能；二是任务权限，限定作业人员处理的任务类型，比如核保员A只能核保某些地区或某些产品的投保单；三是级别权限，限定作业人员能够处理的任务大小。 基于交易中间件的三层C/S体系结构 LifePro核心业务系统基于IBM 的交易中间件CICS进行架构，整个系统分为客户端的功能界面、服务器端的业务逻辑处理和业务数据数据库三部分，通过这种架构可以有效减轻服务器端的处理负荷，解决大集中业务处理模式的性能问题。 单证影像驱动的业务流转，加快业务处理效率和质量 在营业部收到业务单证后，首先对单证进行扫描作业，后续的作业岗位完全基于影像单证进行业务处理，彻底解决物理单证流转带来的处理效率障碍，使业务流程重组及人力资源重新配置成为可能。LifePro目前已经全部实现事后单证的集中扫描、存储和查询功能，全部实现承保业务的单证事前扫描、流转和查询功能。 严格的业务、收付两条线作业模式 在LifePro系统中实现了一个独立的收付费子系统，统一完成个险、团险、养老金的承保、保全、理赔业务的所有类型钱款的实际收付功能，收付完成后实时通知相应的业务子系统，并驱动业务子系统完成后续的业务处理（如生效等）。业务子系统只产生应收、应付款项，并将应收、应付的请求实时递交给收付费子系统。业务系统与财务系统的接口全部通过收付费子系统完成，简化了多个业务系统与财务系统之间的接口复杂性。 功能描述 LifePro业务系统包括：承保子系统、核保子系统、承保子系统、保全子系统、理赔子系统。深圳市核心业务系统与周边系统的关系如下： 系统架构 基于中间件与ActiveX控件的B/S系统结构 每个子系统均由代表业务处理逻辑的服务器端services组件与代表业务功能展现的客户端ActiveX控件两部分构成。 采用紧密耦合的系统接口：通过Service Call实现系统之间的功能调用。 通过message queue实现系统之间的数据交换。 主要问题 LifePro系统只提供了部分简单的生产数据的统计和报表功能，需要进一步完善和加强。 产品全部通过参数化和插件化进行定义，目前产品定义过程只能由技术人员完成，应该提供一套完善的产品定义工具程序，以期由业务人员进行直接定义，并提供各种测算功能以验证定义的正确性。 LifePro系统只记录了每个操作员的作业轨迹，且作业时间以日为单位，无法实现对操作员进行以分钟为单位的量化考核。未来的完善第一是加上作业时间，并按照业务岗位对相应操作员进行分类工作统计，真正实现员工的量化绩效考核，并核算每个操作员的作业效率、作业质量和作业成本。 LifePro与其它业务系统之间的数据仍无法进行有效、快捷地交换，需要归纳各系统不同的数据交换特点，并寻求若干个统一的解决方案。 目前，虽然LifePro的数据模型能够满足以客户为中心的管理，实际运作中的风险保额和理赔等静态数据都能以客户为中心管理并贯穿个险、团险、分保等核心业务系统，但由于实务运作的情况非常复杂，某些业务规定无法达成共识，因此许多以客户为中心的服务（如按客户发通知书）仍然无法落实。 四个核心业务系统应用技术对比 CBPS 江苏综合 业务系统 上海核心 业务系统 深圳核心 业务系统 功能性 核心业务处理 核心业务处理 统计分析 业务处理 财务管理 销售管理 核心业务处理 综合查询 技术平台 开发语言 4GL/EC 4GL/EC C/EC C / Delphi / EC 运行系统 UNIX和终端 UNIX和终端，WIN UNIX和WIN UNIX和WIN 数据库 Informix Informix Informix Informix 应用结构 C/S C/S B/S C/S 建设期望 通过调研，总结出中国人寿对未来核心业务系统建设的期望如下： 系统应该具有相当的灵活性，以适应中国人寿各地业务状况，以及未来业务发展的要求。 要求系统稳定性好、性能优越、易于操作，能支持大业务量的运行，为业务集中管理提供支持平台。 客户资料共享，实现以客户为中心的业务处理。 建立数据标准，定义接口标准，规范系统间接口。 业务管理模块完整，业务工作流程灵活，信息结构完整，技术结构清晰。 加强系统业务权限控制，完善业务管理体系。 增强系统的审计功能，保证数据的完整性、严密性。 三层架构，浏览器页面，界面友好，开发技术先进。 财务系统 现状概述 中国人寿会计核算及财务管理系统(CLAF)从1998年开始与中科软联合进行开发，1999年向全国各分支机构进行推广，目前为版。 根据调查，全国的各分支机构均使用总公司的CLAF系统进行会计核算，无其他财务管理系统。在CLAF系统上，也没有外挂其他相应的系统。仅浙江金华购置了用友的库存管理系统，进行预算制管理。深圳、浙江开发固定资产管理系统，但目前正处于试运行阶段。 日常的收付费操作都是在业务系统中进行（总公司开发的CBPS、OBPS以及上海、深圳、江苏自己开发的业务系统中），收付费操作所产生的原始数据以及业务系统生成的应收、应付费数据通过数据接口流转到CLAF系统。 目前除了深圳、广西、安徽、海南、厦门、天津、青岛实行了所辖区域的财务集中处理（省级集中或计划单列市集中）外，其他省分公司、计划单列市的财务处理只实行了所辖下一级的集中处理（省级的地市集中或计划单列的区县级集中）。财务的核算单位目前主要是地市级分公司或计划单列市的区县级分公司。 CLAF系统的使用人员主要是各财务处理中心的会计人员和财务人员，总公司、省级公司主要使用工资管理和费用管理，与此相关的会计人员使用。 功能描述 会计核算及财务管理系统功能包括财务记账、会计核算、决算及其他财务管理。系统中的功能模块及各模块的关系如下图所示： EMBED 主要功能模块具体陈述如下： 原始凭证管理：接收外部业务系统中的数据；各种原始凭证的录入、查询及修改更新；由原始凭证自动或半自动生成记账凭证。 科目体系管理：科目体系是账务系统的核心。它包括帐套类型设置，帐套设置，核算单位和基层单位的帐套设置，明细值编码设置，科目体系设置，核算方向设置，有效性设置和辅助参数设置。一套账由三个层次构成：账套类型、账套、会计科目。 账务处理：记账凭证的一般管理及复核；记账凭证生成明细账；生成并管理总账和各种辅助账；与输出结果相配套的账本管理；会计月末处理管理；各种角度的查询和分析功能。 财务报表管理：报表处理系统主要包括以下两大模块：报表定义和报表计算。 决算系统：录入决算凭证；复核决算凭证；试算决算；确认决算结束。 其它财务管理： 固定资产管理 工资管理 应收、应付、往来管理 资金运用 系统架构 系统采用了C/S软件架构；主要功能模块开发语言为Informix 4GL/EC和存储过程语言，采用终端字符界面，支持Unix操作系统（HP_UX 、AIX、SOLARIS、SCO OPEN SERVER）；采用Informix数据库；主要的集中处理采用后台批处理程序来进行(从版开始增加的部分，主要解决省级集中所带来的并发性问题，刚刚下发使用)。综合查询与打印管理功能模块原来也是字符终端界面，从版开始采用B/S结构（刚下发使用)，版将前台移植到浏览器环境下，开发语言java,采用浏览器界面。财务报表系统采用C/S结构，使用PowerBuilder和FORMUA ONE软件工具开发，在windows操作系统上运行。 会计核算及财务管理系统与其他系统的接口情况： 核心业务系统：收付费所产生的流水数据、应收应付数据。核心业务系统的相关模块按照约定的格式生成数据文本文件，然后由会计核算及财务管理系统的原始凭证管理模块读取数据文本文件，生成相应的原始单证数据，复核通过后生成原始凭证数据。 财务分析系统：直接从CLAF系统中抽取所需数据。 通用统计系统：直接从CLAF系统中抽取所需数据。 精算系统：精算完成后的准备金数据通过人工输入会计核算及财务管理系统。 缺少相关投资业务的投资管理、资金流管理功能 系统主要部署在进行财务集中处理的财务处理中心（如地市级财务处理中心），往上级单位直至总公司，采用报表的形式上报数据，上级单位直至总公司没有使用该系统（只使用了工资管理和费用管理）。 在系统口令和印鉴两个级别的安全管理模式的基础上增加了数据和岗位两方面的安全控制，同时提供授权管理。 主要问题 功能比较缺乏，只具备会计核算功能。 财务系统的流行做法是系统必须具备总体预算规划、预算计划、预算审核、预算审计、科目管理、账务管理、财务报表管理、审计报表管理、财务决算等功能。目前系统只具备了科目管理、账务管理和财务报表管理，虽然有决算功能模块，但是该功能模块主要用于会计年度末进行调账处理，而不是真正意义上的财务决算（见财务功能说明）。以下是IT战略规划组问卷调查统计结果，从统计结果来看，目前的系统只有科目管理、账务管理和财务报表管理功能，这三部分基本上满足需求。可以说CLAF系统仅具备完成会计核算功能，在财务管理系统支持上处于空白。 与核心业务系统的接口问题： 与核心业务系统中使用的指标含义和标准不一致。 数据在两系统间的共享程度不够,结果造成数据在实时性、准确性、完整性、一致性上的问题：造成业务系统中数据的变更不能及时反映或不能反映到财务系统中；最终的财务记账凭证数据可能与业务系统中的实际情况不符；业务财务入账时间不同。 缺乏财务数据与业务数据相互核对的机制。 数据库安全很难保证。在目前的终端界面模式下，操作人员比较容易直接进入数据库更改数据。 系统处理效率有待提高。根据调研访谈情况，在接收业务系统数据、生成原始凭证、生成记账凭证、月底封帐、生成账簿等功能上，系统效率比较低。特别是多用户使用时，效率更低。 缺乏与一些主要系统的接口，如精算系统、代理人管理系统。 没有与银行建立相应的接口，银行资金没办法实时核对与跟踪。 系统不是很灵活性，不容易维护和实现分布。 建设期望 实现业务财务的一体化管理。首先是建立公司统一的指标体系和数据口径或数据标准；其次是收付费数据要进行充分共享。 借鉴目前全球财务管理和资金管理方面已有成熟的软件和技术方案的思想。希望开发总体预算规划、预算计划、预算审核、预算审计、审计报表管理、财务决算等功能，对财务管理提供技术支持。 用财务对业务进行控制，强调财务对业务的监督与控制职能以保证企业的利润最大化。 开发与其他应用系统(AMIS、精算等）之间的接口，互相衔接，充分共享数据，减少数据的冗余与不一致性。 满足各种数据集中模式和各种营运集中模式的需求，灵活满足各种集中模式下的业务需求和系统运行效率的要求。 改善界面友好性，简化前台操作，提高系统的稳定性。 再保险系统 现状概述 目前没有总部开发的再保险系统。全国只有深圳自己开发了再保险系统，该系统是由深圳市分公司与中青旅尚洋电子技术有限公司合作开发的，目前只完成第一期开发工作，尚在进行第二期开发。2003年9月正式上线运行。 系统中的主要分保业务在后台处理，前台主要是报表展现及部分参数与规则设置，查询与临分分保交互。后台业务主要是各类业务数据提取、各类分保处理。 系统只有前台业务给用户操作，后台业务都由系统运行部门处理。因此，当该系统稳定与正常运行后，大大减轻用户的工作量，其主要工作将变为非电脑业务处理，电脑业务处理演变为主要是报表打印与核对、部分临分业务、查询与统计等工作。 深圳市分公司开发的该系统只有该分公司的核保部使用。 功能描述 深圳市分公司开发的再保险系统第一期功能模块包括：再保险公司登记、法定分保、合同分保规则、正常业务数据提取、法定与合同分保处理、意外险分保处理、分保报表数据生成、分保报表。正在开发的第二期功能模块包括：综合查询与统计、临时分保、团险业务、分出业务、转分业务、财务接口。该系统涵盖了法定分保、合同分保、临时分保等业务。 主要功能模块： 合同分保：后台批处理。合同分保含首期分保、续期分保和变更处理。 分保参数管理：再保险公司管理，合同管理。 取数接口：从业务系统和财务系统抽取相关数据。 法定分保：后台批处理。法定分保含首期分保、续期分保和变更处理。 临时分保：前台操作和后台处理相结合。前台进行临时分保登记和续期确认。后台进行分保处理。 系统架构 系统采用三层结构，由前台程序、中间件、后台交易服务程序和数据库组成，前台程序全部采用WEB页面内嵌控件的形式，客户使用浏览器进行登录与操作。数据库为INFORMIX ONLINE，后台交易服务程序采用Informix EC开发,负责连接数据库和进行业务逻辑处理；采用IBM CICS中间件，更新和维护Tapi和Xapi，使用Visual C++工具开发动态库；前台用DELPHI编OCX,通过DLL与CICS中间件与后台数据交易服务连结。WEB服务器采用IIS。 与其他系统接口情况： 与业务系统的接口：直接用后台程序从业务系统中抽取保单数据。 与财务系统的接口：直接用后台程序从财务系统中抽取收费数据与理赔数据及手续费等。 主要问题 系统相对比较简单，功能很不完全。按照再保险的业务要求和国际通常做法，再保险系统应涵盖如下功能：分保配置管理、分保分出计划、分保分出审核、分出收付费、分出理赔、分出核算、分出现金管理、分出帐务管理、分出报表、分入提交、分入承保、分入理赔、分入审计、分入报表管理、分入账户管理、分入再保险管理、分入结算审计等。通过对照，目前深圳市分公司的系统只是进行了合同分保、法定分保、临分分保的计算处理和报表处理，没有其他功能。 系统不是真正意义上的三层结构，灵活性不够好。由于前台操作时需要从WEB服务器上动态地自动地下载控件，造成网络流通量巨大，系统效率不高。 没有与业务系统、财务系统等实时数据接口，不能最大程度地实现数据共享，很难保证各系统数据的一致性和准确性，也很难进行各系统数据的核对。 建设期望 建立和规范再保险流程，编写详细的再保业务操作手册和实务规定。改变目前的事务性、以帐单管理为核心的流程结构。对再保流程中的关键点和环节进行改造和简化，使之环节少、效率高。 开发全国性的再保险系统。由于目前缺乏信息系统的支持，造成大量事务性工作成为再保的主要日常工作。同时造成工作失误和帐单误差也较多。 能够快速处理临分业务；能对合约业务进行评估和分析。 系统要有灵活性,如对自留额各公司可按不同情况做不同配置，能够提供不同渠道的分保支持。 销售支持与渠道 现状概述 中国人寿销售支持与渠道建设处于起步阶段。从调研情况看，只有浙江等个别公司使用了展业支持系统，大部分分公司不具备比较完整的销售支持系统。 不少分公司使用了一些基本的计划书制作系统或电脑记事本，对业务拓展提供帮助，但未能起到真正的销售支持。 目前人寿保险公司正组织试点“中国人寿销售支持系统”（Marketing Support System），提供了广大营销员需要的客户管理、活动管理、保费试算、业务规则查询、活动提醒、续费提示与业务跟踪等功能。 从总体上看，销售支持系统的开发和推广需要注意以下环节： 避免成本较高，代理人或公司难以承受。 界面应简单易用，适应代理人操作。 功能完善，具有实际应用效益。 功能描述 从我们调研了解的情况看，“中国人寿销售支持系统”由4部分组成：随身通系统、掌上通系统、网络通系统、晨会系统。 随身通系统 个人代理人销售支持系统 (以下简称系统) 随身通版是专门为辅助寿险营销代理人(以下简称用户)开展日常业务活动而定制开发的保险行业应用软件。 它主要提供计划书制作、个人事务助理（个人准客户管理和日程安排）、险种资料查找等与业务活动息息相关的展业支持。 数据更新与维护上，可与PDA进行选择性的数据同步与备份，以确保业务信息的全面、及时、准确。 掌上通系统 掌上通充分利用了PDA小巧易携的特点，将客户管理、险种资料、活动管理、保费试算等展业过程中不可或缺的功能集中提供，让代理人从传统的纸笔卡片手册资料中解脱出来，把全部的精力用于产生业绩的展业过程中去。 网络通系统 网络通的功能与随身通相似，是随身通系统以web方式在网络上的应用。 晨会系统 晨会辅助经营系统通过对寿险业务单位经营现状的分析，结合业务单位经营背景和晨会运作的具体要求，为业务单位提供量身定做的以经营主题、专题为主的晨会行事历。同时，本系统的素材库提供包括晨会专题、业务推动奖励方案、激励故事（口号、歌曲）、游戏幽默、相关知识等用于晨会经营的可供编辑的素材，全方位地辅助业务部门轻松经营高品质的晨会。 主要问题 中国人寿保险业务的快速发展导致对信息系统支持销售的要求越来越迫切。 业务必然由于销售支持系统是处于初期建设，且系统试用范围比较窄，业务部门对其总体应用的反馈不足。但从总体上看，其主要问题包括： 目前销售支持状况难以满足业务发展要求。 由于中国人寿自身缺乏深层次客户分析、产品分析和业务分析的应用功能，缺乏市场深层次分析经验，造成实际的销售支持功能设计不足。 由于核心业务系统处于发展阶段，整体规范接口和整体结构处于完善过程中，销售支持系统如何从系统中获取数据、获取那些真正有价值数据的设计不清晰，也影响实际应用效果。 建设期望 通过对团险销售人员展业系统功能要求的调查分析，％和％的销售人员认为该系统中应分别包含计划书和产品测算功能，此外对业绩管理查询和日常活动管理功能的需求比例分别为%和%。 而在个人销售支持方面，其销售支持期望总体状况如下： 关于公司网站对个人销售支持方面的调查 Cases Col Response % 网站支持 营销知识 538 % 精英经验及风采介绍 497 % 销售话术 477 % 险种介绍 468 % 其他 51 % Missing 1 .1% Total 725 % 关于公司在个险销售支持方面的调查 Cases Col Response % 销售支持 广告 576 % 新险种开发 539 % 销售工具 365 % 网站 364 % 95519 317 % 其他 28 % Total 727 % 关于笔记本电脑展业支持系统方面的调查 Cases Col Response % 笔记本展业支持系统 计划书设计系统 676 % 客户资料库 635 % 业绩管理查询 475 % 活动量管理 395 % 其他 42 % Total 716 % 总上所述，销售支持系统的主要客户期望为： 开发功能简单易操作、低成本的PDA、单机版和网络版展业支持软件。 要提升代理人销售的专业形象，应考虑代理人的承受成本和其普遍文化素质，协助其逐步建立客户关系管理理念，并逐步过渡到使用复杂而又专业的展业工具。 完善展业支持工具的功能。 主要是展业的软件，内容可以包括得多一些，代理人的身份证明、计划书制作、中国人寿的介绍、险种介绍、公司的服务系统、可以向客户提供的附加值服务。同时最好能将同业公司的相关材料也写入，便于查询与比较。 建立客户需求分析模型。 完善客户关系管理系统，能够实现对客户进行细分。在对准客户进行保险需求分析时，能够根据历史数据提供销售的指导性和针对性（数据的评估、销售佐证），给客户一个科学的判断。计划书设计并不重要，而是要提供分析模型。（如数据分析、销售依据并可以转化为文档） 迅速推广代理人展业支持系统。 尽快将代理人展业支持系统进行完善，并进行推广，同时配合组合销售的推广，建议将组合销售工具的内容电子化，并与活动管理电子化的软件一起加入到展业支持系统中。使部分已拥有手提电脑（占全体业务员的5-10%）的人员尽早使用已有的软件，也能在代理人队伍中做到标杆作用。 决策支持系统 现状概述 中国人寿目前决策支持系统主要是提供业务综合查询。主要使用部门为各级业务管理部门和决策层。 目前应用的业务查询方式包括： SAS系统分析 部门和省使用EXCEL等工具进行的管理分析 系统提供中国人寿保险公司的每一级机构的每一位管理者和代理（业务）人员能比较及时、准确和全面地了解和掌握他责权范围内的各种信息，如：客户信息、业务状况、财务状况、员工工作业绩等，实现信息资源共享。 在业务、财务、精算、代理人管理等应用系统间藕合度比较松散的情况下，查询系统将要作为各系统间联系的纽带，采用统一的操作界面和丰富多彩的信息展现形式，为各级应用层提供简便、快捷、易学的决策支持服务。 功能描述 从中间库基础数据的数据量和增长性度量值考虑，今后考虑采用数据仓库技术来组织基础数据中间库结构和稳定性以及从业务数据库抽取到中间库数据的及时性和准确性将是影响综合查询系统至关重要的因素。针对信息查询功能，系统设计时，为确保展现的中间库数据与就用系统的实时数据一致，在展现查询结果的同时对中间库相应数据进行刷新处理。 经清理、抽取、加工后的数据将按详细数据层、统计数据层的预定制数据层等数据层面存放在查询数据（仓）库中，分别提供不同应用层的服务（查询、统计、分析），以提高系统运行效率。 主要功能划分为：查询、统计、分析、决策、监控等几部分。能够针对不同的机构、不同部门、不同的查询对象，定制不同的查询内容。前台强调查询条件和查询结果灵活设置，运行高效性。 系统架构 通过开发的抽取程序将系统所需的基础数据抽到中间库中，并通过清理、加工、整合等工序，将中间库中的数据添加到查询库中。如图示： 查询系统采用三层体系结构实现，系统后端为数据库服务器，中间层为应用服务器（分析引擎考虑采用专用工具），前端是集成化的数据分析展现工具。 数据库服务器实现数据的采集、抽取转换以及数据的存储功能，数据的抽取、加工与系统维护功能目前采取人工编程方式实现。 我们将查询数据库与中间库放在相同地点即省分公司和总公司（建立DB Server），采用以WebServer/Browser方式为主的展现形式为不同机构（建立Application Server）的不同用户提供不同层面的服务（查询、统计分析、实时监控及决策支持等）。 采取基于web应用服务器平台:数据库服务器：Unix、Informix数据库；中间层服务器：Windows、IBM Websphere；开发工具：IBM Websphere Studio、Iinformix ESQL/C等。 主要问题 目前，大部分公司财务、精算、业务、销售、咨询、投诉、业务员信息等分别在不同的系统中，特别是业务又包括几个不同的系统，各地的查询系统仅从以上某些系统中取数，而没有一个囊括公司全部业务系统相关数据的平台进行查询支持。 各种数据的口径不统一，目前数据主要涉及到财务、精算、代理人、业务等多个系统，各个部门的报表口径不一：如“新单保费”的概念，到底包括不包括月缴，再如某个险种，到底是按照团体险统计还是按照短期险统计等。各种口径不统一加大了系统间接口的复杂，增加了数据准确性、一致性、效率控制的难度。 总之，目前决策支持系统主要问题是： 缺乏整个公司统一的分析指标体系，缺乏如精算分析、财务分析指标在内的公司总体效益分析体系。 缺少全辖范围内各种业务类别的完整统计分析。 统计报表多人工操作，费时费力。 数据规范性差，数据一致性差。 Lapse anlysis over all province(whole cuntry) 建设期望 根据上海、深圳等公司应用经验，基础统计指标体系的建立是非常关键的。应在全公司采用统一的统计分析指标，为建立统一的查询、分析系统奠定基础。 决策支持系统建设期望主要包括： 建立实时准确的业务统计分析系统。 建立基于精算、财务指标的总体企业效益、风险、负债分析。 建立综合业绩分析系统。 业绩分析系统是为了满足当前各级公司管理人员的决策需要，该系统中包含了原来设想的渠道管理系统中的系统功能。包括： 销售状态分析，即按照时间、公司、险种三个角度对团险各险种的保费收入、给付、退保、计划完成率、增幅、业绩排序等进行分析； 销售渠道分析，包括团队、个人的险种结构、给付、销售业绩、人均产能统计和排序，以及经纪公司、代理公司的销售收入、赔付率和退保率。 基于客户分析的决策分析系统。 现有客户群体特征分析：客户的行业、规模、所有制特征、单位关键人物描述、接触过程描述。 现有客户承保行为分析：某时间点或时间段的保费收入、同比情况、客户群体占公司的保费规模、客户群体对某险种的需求特征、查询保费规模较大的客户、客户投保的变化、客户的给付（赔付）情况、保费规模大且赔付率高的客户名单统计分析。 现有客户质量综合分析：某一时间段的费用贡献、赔付情况的统计分析、红利分配比例。 潜在客户分析：规模大且保费低的现有客户名录、期末保费同比降幅较大的客户名录、与公司有过接触、行业转暖、财务状况趋好的潜在客户名单 周边系统 客户服务系统 现状概述 目前中国人寿客户服务系统建设处于初步实施阶段，主要是以建设涵盖全国范围的呼叫中心为主。 中国人寿客户呼叫中心由全国集中的管理配置中心、省呼叫运营中心，以及部分地市服务接入网关和本地坐席组成。 该方案实现了主要系统和运营集中管理配置，服务省级分布组织、服务可按业务要求延伸到基层机构。 呼叫中心建设目前已经完成上海、江苏、深圳、四川一期4省实施。目前按计划正组织北京、新疆、广西3省二期实施。其余省推广实施方案正计划之中。 功能描述 中国人寿呼叫中心系统结构示意图 客户服务系统基本情况是： 呼叫中心系统设计采用了先进的VoIP技术，充分利用了现有中国人寿网络资源，大大降低了电信运营成本。 实现了呼叫服务全公司的集中管理。 实现了服务分布组织，满足业务上服务贴近客户的要求。 实现了服务按业务要求灵活延伸。 中国人寿呼叫中心功能界面示意图 主要问题与期望 整体上看，中国人寿全国范围内的呼叫中心建设无论投资规模、运营成本、技术方案选择上，在国内金融行业应处于领先地位。 中国人寿呼叫中心总体方案正成为保险公司原有呼叫中心技术升级的主要选择，而且从系统运营效益看，也基本实现了原有建设期望。 随着中国人寿业务的快速发展，原有呼叫中心的建设步法和基本系统功能正面临更大的挑战，主要包括： 呼叫中心实施速度还未能完全满足业务要求，可以支持客户服务和代理人服务的要求。 其他渠道或深层次客户服务如Web、CRM支持等，业务部门已有明确需求，但尚未有明确计划。 代理人管理系统 现状描述 当前中国人寿各地市，除江苏，深圳，上海外，均使用总公司的代理人管理系统(Agent Management Information System)，该系统以个人代理人管理为核心，实现了个人代理人档案信息管理和业务信息管理，其最新版本为，提供月度标准报表有18张之多。 Amis系统应用主要构建在省级或地市级公司，对整个代理人的档案及经营活动进行管理，保存个人代理人的有关资料，使我们能监控其工作表现并决定其报酬。 功能描述 Amis系统的功能模型如下： 个人代理人管理系统所包括的核心功能如下表： 数据维护 查询统计 报表维护 职级管理 业务计算 保单处理 系统维护 增员处理 人员维护 人员调配 立案登记 减员处理 离司审核 单位维护 单位调配 上载数据 个人日业务 单位日业务 个人月业务 单位月业务 收支情况 佣金汇总 综合查询 档案信息 生成报表 查询报表 职级晋升 职级下降 职级维持 合同终止 单位分离 新人回归 下载日数据 下载月数据 每日汇总 每月汇总 收支计算 考核计算 取消汇总 月末确认 比例调整 孤儿保单处理 有效保单处理 保全新单处理 操作员 营业单位 查询栏目 总公司Amis系统的开发语言为4GL/EC，该系统运行在Unix操作系统上，采用Informix数据库。 Amis系统具有如下特点 具有良好的系统动态扩展性。 提供了良好的统计查询分析功能和灵活的报表功能。 拥有一套独立的数据库表，与业务系统通过建立中间表使得双方联系起来。 提供灵活的制作、生成、查阅、打印各种年报、季报、月报等报表功能。 主要问题与期望 加强对代理人考核灵活性机制和流动情况统计分析的支持。 加强代理人管理信息系统的辅助预警系统的开发，以完善Amis的监管代理人功能。 减少升级的次数，完善系统的稳定性和拓展性。 采用成熟，稳定和开放的应用构架。 精算系统 现状概述 中国人寿保险公司目前使用的精算系统主要是运行在总公司的责任准备金系统和运行在部分分公司的处理与分析系统。 目前的精算系统是人寿自主开发的，系统面向寿险业务分析，主要是实现逐单责任准备金计算，形成精算报表，为公司提供决策管理数据，其主要特点包括： 建立了责任准备金逐单、按险种类别计算。 实现了精算功能的模块化，能够根据计算公司自动生成程序模板。 具有支持地方险种精算接口，可以对基础数据进行错误检测，提供了利源分析、费用统计等管理支持。 功能描述 由于中国人寿目前尚未实现全国的数据集中，没有全国数据中心支持精算系统运行，因此，精算系统需要通过系统接口实现数据访问。 精算系统主要功能包括： CBPS数据转换子系统 数据传送子系统 准备金计算子系统 数据汇总及报表处理 主要问题与期望 通常保险公司的精算工作主要在企业先期产品设计定价，业务处理中的分析与评估，业务管理过程中风险管理控制与企业总体效益分析等，保险精算所要求的信息数据、分析工具或分析功能是非常多的。 目前中国人寿保险公司精算应用的主要问题是： 未能建立企业全国范围的数据中心，难以对中国人寿积累下来的宝贵保险业务数据进行全方位的使用。 目前各地手工上报数据存在不一致性，存在对上报精算数据的再修改，降低了业务分析的可靠性。 未能通过业务数据进行客户或业务的细分分析，未能在产品开发、业务实时管理上发挥精算作用。 不能实现按月进行精算分析。 不能有效支持定价和利润测算 不能有效支持进行业务规划分析和业务布局规划分析 电子商务系统 现状概述 中国人寿的电子商务系统处于起步阶段。 总公司和部分分公司建立了企业门户。 实现了基本的信息查询、简单的保费试算等功能。 深圳分公司已经开始电子商务系统的建设招标。 主要问题与期望 电子商务系统在保险行业的应用正处于探索实践阶段，国内泰康（泰康在线）、平安（PA18）等保险公司已经推出了自己的电子商务系统。保险网站的经营宗旨一般不外有三：一是建立一个面向客户进行宣传、推销保险的平台，二是进行网上销售即电子商务这一环，但目前主要还在摸索阶段；三是提供保险后续或外延服务，如网上查询、更改资料等。 目前人寿电子商务存在的主要问题是： 各分公司的门户网站没有统一的域名管理，没有统一的形象展示。 总公司门户上没有分公司的网站的链接。 与业务系统接口不畅通，网上数据不及时。 电子商务系统缺乏统一规划，发展方向、建设步骤不明确。 根据调查和访谈，对未来电子商务的建设有如下期望： 电子商务建设要形成以客户为中心，集客户、营销员、公司管理人员和公司决策人员于一体的信息交换平台。 逐步开展在线投保、信息查询、批改（保全）申请、在线报案、网上出单等业务流程，同时为客户提供个性化的服务。 与核心业务系统进行整合，交易信息对接，实时处理。 电子商务必须以服务客户、业务人员为主，以及方便客户查找、分析为主，可以首先实现企业对企业电子商务，即尽快建立统一的保险银行的电子商务平台，充分利用银行的网点优势，方便客户，降低成本，而且从技术上、市场需求上讲都是成熟的。 要有足够的前瞻性、扩展性、兼容性，安全、可靠、易维护。 实现B2B 业务支持和服务支持 OA系统 现状概述 中国人寿保险公司OA系统是基于Lotus Notes的办公自动化系统建立的，其主要特点为： 建立全系统员工的邮件系统。 实现了总公司和部分省市分公司的内部邮件通过Internet和外部邮件互通。 建立了内部网站，实现了办公收发文流转共享。 主要问题与期望 从应用体系中不同分类应用调查分析看，中国人寿保险公司OA系统并不属于首要发展和最需要改造的前三个应用之中；同时，在目前比较好的应用系统中出现的比例较大。 因此，OA系统的基本状况为： 现有OA系统基本能够适应目前业务应用要求。 OA系统总体结构和功能总体满意度较高。 未来OA深层次升级发展的要求，如移动漫游办公、网上审批、网上办公等应用发展的期望，其实施优先级比较低。 应用架构差距分析 优势与问题 优势 根据上述分析，中国人寿保险公司应用架构基本上能够应对目前业务处理的要求，其具体优势体现在： 应用架构中主要的IT应用系统已经建立 在现有应用架构中，业务系统、财务系统、OA系统、责任准备金系统、网站、呼叫中心系统等都已在支持目前的业务运营。 其中，部分系统如OA系统、呼叫中心系统等其系统结构、功能和业务支持能力相对比较先进和完善。 业务处理功能比较丰富 现有的处理功能包括了承保核保、理赔、销售支持、客户服务的基础功能，涵盖了中国人寿保险公司的大部分业务处理环节。 从基本业务处理功能分析，目前处理功能能够满足日常业务处理要求。 总体应用的技术选择较为适用 现有系统中，已有不少系统应用了先进；如不少系统采用了B/S结构，呼叫中心应用了IP技术形成了系统集中管理、服务延伸的架构；OA系统能够支持内外部邮件，并实现公文发布。 问题 在基本支持目前业务处理要求的同时，应用架构如果不能及时进行较大的改造，就会影响公司业务的发展，其主要问题包括： 总体系统规划组织方面 缺少一个应用架构规划设计的整体协调机制，从市场－产品－营销－管理服务业务需求组织； 应用架构实施缺少高水平的业务分析支持，普遍反映认为应用架构支持的业务管理流程和业务实物操作和一线业务应用要求之间存在距离 缺乏总体规划和架构设计 业务处理功能结构方面 整体保险业务业务处理功能不足，同未来产品和业务发展要求相比有较大差距； 团体险业务处理功能不足问题较为突出； 产品配置管理支持不足； 投资连接功能支持不足； 功能结构分散，服务支持能力差； 系统扩展性差； 数据一致性差； 系统需求方面 电子商务处于较低阶段，同公司整体业务发展存在较大距离 决策支持系统欠缺 再保险处理系统欠缺 精算与风险管理系统欠缺 应用设计资源方面 认为总公司IT应用技术力量弱，技术资源少，组织效率低，总公司技术指导、技术应用实施大大跟不上业务发展要求 需求与期望 中国人寿面临的是业务发展环境主要特点包括： 日新月异的保险产品和快速发展的客户需求 激烈的市场竞争 日益突出的管理效益挑战 因此，应用架构规划主要解决的问题不仅仅是应对目前日常业务处理要求，更多期望解决业务扩展服务和管理控制支持： 提高应用系统的扩展能力和扩展速度； 支持及时准确的管理支持功能，如数据分析与决策支持； 支持适应未来客户服务要求的系统处理功能，如一站式处理支持或柜台处理支持； 支持多渠道营销服务，包括PDA、电子商务等； 支持风险管理、再保险、产品开发、精算等日常业务管理； 完善业务系统处理功能，提高系统效率，提升系统运营维护水平； 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 改进建议 Action 41 总体设计差； 系统结构不清晰； 应急开发； 缺少规划； 缺少完整项目实施管理；统一设计； 应用架构/系统结构 建立IT发展策略； 建立IT总体项目实施规划； 建立应用架构的总体实施策略； 42 功能分散； 服务能力差； 运营维护不足； 扩展能力弱； 缺少完整解决方案； 缺少层次性组件化功能结构； 应用的系统功能 建立新一代应用系统总体框架； 分布建立各个应用子系统模块； 43 开发技术较强； 设计能力较弱； 总体业务分析能力弱； 总体系统分析设计能力弱； 整体应用状况 加强先进技术交流、引进； 加强系统开发实施中的强强合作； 44 开发支持资源不足； 分析综合能力弱； 技术人员不足； 缺少开发协作和技术培训； 整体应用状况 加强技术资源建设；协作研究和开发； 应用架构评估总结 应用架构评估通过资料分析、数据采集分析、访谈从下面三个方面对人寿应用系统进行了评估： 整体架构 主要业务处理和管理应用系统 周边系统 总体上看，目前中国人寿保险公司应用架构的主要状况为： 应用架构仍处于初期构建过程中，业务发展对应用系统要求较为紧迫，应用系统开发完善压力大； 应用系统能够应付目前主要业务处理要求； 应用系统未能很好满足业务发展要求； 应用系统总体结构、系统开发设计、功能组织等方面还存在较大不足； 应用系统的主要问题包括： 缺乏总体系统规划组织规划，缺乏高水平的业务分析支持，缺乏总体规划和架构设计； 业务处理功能结构不足，部分业务产品（如团体险、医疗健康险等）支持不足，功能数据结构分散，服务支持能力薄弱； 缺乏深层次应用企业管理支持系统，如决策管理支持系统，精算与风险管理系统，再保险处理系统欠缺，销售支持系统等 应用设计资源不足，系统运营维护支持、开发管理等能力不足 解决目前系统问题的主要可能的策略包括： 根据业务发展规划，决定未来产品与市场策略、决定业务组织管理模式，并基本建立适应未来业务发展要求的完整业务流程 结合产品营销策路、业务结构和业务流程，建立应用架构总体实施策略和总体应用实施 建立主要项目的实施规划，建立新一代应用架构 加强技术交流和技术引进，提升应用水平； 加强技术资源建设；协作研究和开发； 数据架构调研与评估 数据架构是指企业总体的数据采集、处理、存储和管理等的总体架构，区别于应用架构，数据架构主要侧重于业务处理所需的信息和信息流，包括： 总体架构：数据模型的组织方式 数据标准化：企业级数据定义的标准化及管理水平； 数据质量：数据的准确性； 数据管理：对IT系统中的数据管理，包括：存储组织、清理、访问控制等； 总体数据架构 现状描述 目前，中国人寿的总体数据架构的建设是一个自底向上的过程：通过建立一个个应用，产生相应业务区域的数据模型，然后根据需要建立这些数据模型间的数据接口，从而以逐步“联接”的方式，形成中国人寿的总体数据架构。 下图描述了这种基于应用建设所建立起来的数据架构： 上图摘自《中国人寿应用系统介绍及计划》，它描述了整个中国人寿主要的应用系统间的关联和数据交换，从总体上看来，中国人寿： 基本实现了业务信息的电子化，绝大多数业务处理都有应用系统支持； 主要的业务功能区域（如寿险实务、财务管理等）的信息处理都有较为成熟的应用架构和数据架构； 各个应用系统之间可以利用数据文件进行数据交换，实现了信息的传递和共享； 银保通系统能够实现和银行间的实时数据交换； 基于数据库技术的信息处理体系基本成熟； 初步建立了以中间库为基础的数据交换平台，并基于它实现了企业数据综合查询统计功能； 初步建立了以统计报表工具为手段的数据统计和报表系统； 财务系统利用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己的数据仓库系统； 基于NOTES的消息系统支持了公司的日常信息沟通工作； 基于影像技术的非结构化数据正在一些分公司使用，并逐步推广。 数据模型和应用的相关性 以应用为划分的“烟囱”结构，数据基于应用，并被锁定在应用系统中 数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺乏相互之间的协调，因此，数据模型基本按照各个应用系统的功能需求进行设计和实现； 由于缺乏有效的数据共享，在有些业务环节上，一个应用所需的数据无法从相关的其他应用系统中获得（如AMIS和财务系统间需要共享代理人佣金信息），而只好重复录入； 另一方面，由于同一个数据可能存在多个数据源（从多个应用系统中被重复录入），由此导致了信息的不一致。 核心业务系统的总体数据组织主要是保单处理为中心，而较少倾向于以客户为中心； 结构化数据基本上都利用数据库技术实现，非结构化数据只有少数地方使用影像技术实施了电子化，从应用程度上两者之间的集成度不高，影像工作流技术和其他应用系统之间没有能够做到无缝联接。 缺乏自动化和实时的数据交换 以数据文件交换为主要手段 现有的数据交换方式通常是从一个应用中将数据导出到平台文件中，再传递到目标平台并并导入到目标应用系统中； 由于大批量的数据抽取工作会影响到正常的业务处理效率，因此通常的数据抽取都被设定在在晚间进行，所以数据的时效性较差（通常都在一天左右）。 数据交换过程缺乏严格的数据校验、过程控制等 接口数据的错误经常是在导入目标系统时才发现，而不是作为系统数据质量控制的一部分，预先在源系统中进行合法性校验； 数据交换的过程缺乏技术性控制：诸如大批量数据分割、数据传输的校验、重复操作的处理、操作回滚等。 对不同版本或开发商开发的，支撑同一业务应用，缺乏统一规定的应用系统数据外模式 例如业务处理系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统（如CLAF）的接口需要各自编写相应的接口软件来实现。 从较好的做法上，对同一业务处理过程，应当定义标准的接口模式，并以此作为软件开发的指导或标准。例如：中国电信就对所有的计费系统开发商定义了系统对外接口标准，并禁止其分支机构购买不满足这一标准的产品。 数据物理层次和数据提升（staging） 数据提升是指企业范围内，数据从原始的事务处理细节数据，到各级汇总数据，到决策支持分析模型的逐层传递和转换过程。数据提升的目的，是为了向各级业务部门提供查询或分析所需的不同汇总层次的数据。 事务（transaction）处理层数据 应用系统中存储了完整的、原始的事务处理数据； 应用系统中的主要事务处理数据都具备时间戳等增量识别标志； 没有后备系统存储离线历史数据：包括用于存储历史数据的存储系统和用于质量控制的测试系统； 数据分布在各个省公司或地市公司的应用系统中，多数省份实施的是服务器的物理集中； 原始业务数据没有从省公司到总公司的复制； 基本上没有省级逻辑集中的各省都已经实现将业务数据从地市服务器到省服务器的每日复制，实现了省级综合查询功能； 数据集成平台 缺少完整统一的集成平台来集成各应用中的数据，建立企业级信息视图 轻度统计汇总数据 利用应用系统自身的报表功能和统计功能实现； 省级和地市级的IT人员完成了一定的查询和报表开发工作，以满足业务部门的小规模要求； 对于应用系统中没有的报表，利用手工（UTAB或EXCEL）实现； 总公司层面缺乏对轻度汇总数据的全面集成； 高度汇总数据 应用系统中具备部分高度汇总统计功能； 对于应用系统中没有的报表，利用手工（UTAB或EXCEL）实现； 由于手工工作太多，人为因素影响了数据的完整性和准确性，使得数据准确性和可信度不够高； 决策支持模型 缺乏灵活的系统统计分析功能； 缺乏企业级统一的数据平台，从而也就无法建立企业级的决策支持分析模型； 目前的SAS系统主要基于财务数据的分析。 外部数据交换 和银行之间，通过中间服务器实现了实时的数据交换； 和监管机构的数据交换通过报表的方式来进行； 缺乏和其他机构（如公安系统）等的数据交换。 差距分析 用户期望的状况 通过调查，用户的期望集中在： 未来信息系统必须有长远规划，可支持多种管理模式； 加强信息系统的整合，建立对内对外信息披露的统一的、高效的平台，满足业务管理、销售支持、决策分析等各方面需要； 系统建设要面向客户和市场，支持业务流程和管理优化，支持应用系统在不同用户界面或渠道的拓展，如Internet、电话、多媒体终端等； 充分利用录入的原始数据，提供丰富的、方便的统计查询及分析功能；指导我们的管理工作；业务处理和行政管理规范化、自动化、流程化、无纸化；另外，通过信息系统建立预警机制，加强业务监控； 信息系统由封闭走向开放，将员工、客户、业务员、代理机构、合作伙伴有机结合起来。 用户认为目前信息系统距离业务需求的差距（优先级） <本章中的图表，除特别说明外，均出自本次规划的调查问卷统计结果> 从上图中可以看出，目前的应用系统信息处理效率不高是用户反映最多的问题，其次是信息量不丰富和准确性不够。因此，上述各项中，建立高效的数据处理应用系统和统一集成的数据整合平台是用户的重点期望。 差距及原因 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 改进建议 Action 整个信息系统缺乏总体性，数据接口设计、开发、维护、升级等工作复杂 没有总体的业务信息流的定义，从而无法进行总体的数据流设计 所有应用 定义业务处理的信息流，在此基础上定义信息系统的数据流，统一应用间数据交换定义 企业级总体监控信息难以获取，时效性差 没有总体数据架构规划 没有建立数据提升系统来整合原始业务数据，并逐级汇总 业务监控、管理和决策 分阶段建立企业级统一的数据平台（One-View），包括：基础数据平台、各汇总层次数据、决策支持模型 信息系统的组织和设计是面向业务流程处理的，而不是以客户为中心的 旧的业务管理模式是面向处理流程的 所有业务管理和客户服务 建立以客户为中心的业务管理和客户服务模式，在此基础上按照CRM的理念改造现有信息系统 数据标准化管理 现状描述 基本上所有的业务和IT人员都充分认识到数据标准化对业务的重要性，但往往数据标准化被认为是IT部门的工作，而忽视了建立数据标准化的基础：业务信息定义的标准化； 但实际上，除了部分代码标准是总公司下发的以外，业务部门并没有统一制定业务信息的标准定义，因此，IT部门也就缺乏必要的、统一的依据来制定数据标准； 从业务指标体系上，没有一个从总部制定的统一指标和统计报表体系，各不同部门、不同分支结构都有自行制定的统计报表，结果导致整个系统乃至报表制作人员的工作负载过大，重复工作也较多，最终的结果是导致报表的数据全面性和准确性下降； 从组织保证上，并没有一个指定的团队来负责业务信息乃至数据定义的标准化工作； 各应用系统的开发商不同，而中国人寿对各供应商在数据标准化上也无法进行有效的控制，导致所遵循的数据标准不统一； 由于总颁应用系统普及面较广，对某一个具体的业务应用来讲，使用该应用系统的数据标准基本是统一的。 现有数据标准制定和管理制度 数据标准的制定由应用系统开发商负责，而不是由一个独立的数据规划部门负责； 开发商遵循自己的数据标准制定流程进行管理，基本属于开发管理的范畴，而不是IT管理和规划的范畴； 现行的数据管理是面向最终数据结果（如统计报表、精算数据准备等）的，而忽视了数据定义和处理的标准化，各地对同一个名词的理解和定义可能都不相同。 差距分析 用户期望的状况 对业务的重要性： 在对现状调研的过程中，无论是业务人员还是IT人员，所有的受访者都一致认为信息标准化程度对业务是非常重要的。 业务信息标准化的优先级： 上图是业务人员对信息标准化优先级的反馈统计，而从IT人员的反馈来看，唯一的区别是他们认为最优先的应当是业务操作过程信息： 综合业务和IT人员的看法，我们可以认为，保单信息、客户信息和业务操作过程信息是当前最迫切的标准化需求，也是进行数据整合是实施数据清理的重点工作。 信息标准无法贯彻的原因： 由上图可以看出，几乎所有的受访者都认为标准无法贯彻的原因是没有管理制度；因此，我们初步认为，中国人寿有着很好的标准化实施基础，而制定和贯彻标准化管理制定是这项工作的重点突破口。 差距及原因 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 改进建议 Action 应用间甚至业务功能和部门间信息沟通复杂 没有统一数据标准 所有 建立统一的业务信息标准，并在此基础上建立统一的数据标准 数据标准的贯彻能力弱 缺乏授权的流程的制度保证标准的贯彻 所有 建立数据标准的制定、发布、维护流程，并建立定期审计制度； 严格控制应用开发的数据标准，将其作为开发项目验收条款的一部分 数据质量管理 现状描述 数据质量管理现状 现行的数据质量标准 中国人寿没有全公司范围的数据质量考核体系，现行的数据质量评价主要通过以下几方面进行： 业务考核或报告中，数据统计的准确度和完整性； 应用系统运行时所执行的业务逻辑校验； 数据交换时的合法性检查； 现有的数据质量控制方法 应用系统所实现的校验逻辑和业务规则； 数据交换时的合法性检查； 应用系统间的数据对照； 现行的数据质量管理制度 缺乏完善的对数据录入人员的数据质量考核体系； 缺乏对开发过程的数据标准化控制； 缺乏系统上线流程中的数据迁移管理； 缺乏对应用系统运行过程中的数据质量审计和考核体系。 现行的数据质量管理工具 现行的数据质量管理工具主要是为数据接口所开发的校验程序，用于发现交换数据的错误； 由于没有企业级统一的数据平台，因此，也就没有全司范围的数据质量监控和数据自动修正工具。 现有数据质量问题 现有的数据质量问题主要表现在： 相对于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的要求； 系统校验控制不严谨或BUG导致的数据错。 管理员为保证业务的运行，在取得授权的情况下，直接修改数据库后台数据，由于对应用系统的熟悉程度的差异，导致出现数据不一致； 升级和移植过程中数据转换或迁移操作错误，导致的数据错； 差距分析 用户期望的状况 在调查中，几乎所有的用户都认为目前的数据质量无法满足业务监控的要求，但是，其中的多数用户都认为数据质量问题集中在老业务中，也就是说，用户对目前应用系统产生的数据的质量还是可以接受。 对于今后的数据质量控制措施，用户主要的反映集中在： 提高系统事后监控能力，通过数据的扫描和比对，发现数据错误； 提高数据交换的实时性和自动化程度，减少由于时间差和人为因素导致的接口数据错误。 加强系统上线和升级的测试工作，减少升级导致的数据错误； 差距及原因 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 改进建议 Action 现有历史数据质量无法满足以客户为中心的要求 由于业务需求和应用逻辑定义不完善，导致历史数据不完整 缺乏完善的数据质量考核体系 所有 在建立以客户为中心的业务模型的基础上，尽量补齐或修正所需的客户信息和相关交易信息； 对无法补齐或修正的数据，发布数据质量报告，明确告知最终用户； 对于现在后今后产生的数据，建立严格的数据质量考核体系，加强应用操作，尤其是数据录入的监督 系统升级越频繁，数据质量越差 系统开发缺乏严格的测试，导致BUG引发的数据错误 系统升级时没有系统地考虑数据地迁移和转换过程 系统升级和维护 建立需求部门负责把关的严格的测试体系，对应用系统 引入解决方案部署过程（Solution Architecture and Infrastructure Design），保证系统升级过程更加系统和完善; 将系统的部署或升级方案作为应用开发验收的一部分 管理员人为修改导致数据质量下降 业务需求定义不完善 应用系统不灵活 管理员对应用系统处理过程及表之间的参照关系不熟悉 系统维护 建立统一的数据直接修改流程，严格控制直接后台修改的授权、修改方法和测试过程 应用系统数据管理 现状描述 应用系统数据维护 CBPS应用系统数据维护描述： 业务逻辑控制（数据校验） 不允许为空数据的强制录入控制 业务规则校验 变化幅度异常的数据 目前的应用系统中上述方面做的比较好，但在以往的应用系统由于需求定义不完善的原因，存在由于上述控制不完善导致的非正常数据。 数据扫描和一致性校验 应用系统没有的错误数据清理工具； 没有实施例行检查操作, 把正常情况下要到今后某一时刻才反映出问题的数据(如接口异常)，再提前找出来处理掉； 错误数据清理 目前没有应用系统自动的错误数据报警和清理功能； 错误数据清理仍是相当艰巨的工作； 部分分公司做了错误数据清理工作； 历史数据卸载 系统设计时没有考虑历史数据卸载计划、 卸载机制； 缺乏历史数据卸载这方面的知识和经验； 直接后台修改 系统中存在错误数据，导致前台无法正常操作，需要后台修改。这部分比重相对较大； 由于某些功能程序不支持，需要后台修改.； 后台修改一般采用会办单的形式流转； 复杂问题的诊断，较为慎重的做法是在测试库上模拟验证； 系统升级和迁移 系统升级和迁移频繁； 升级和迁移时缺乏良好的测试，导致出现操作不正常，以及数据错误。 上海应用系统数据维护描述： 业务逻辑控制（数据校验） 不允许为空数据的强制录入控制 现有系统对数据录入的控制较严格，目前存在的某些数据字段为空的原因是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入。 业务规则校验 目前存在的业务规则校验问题主要是： 历史数据没有满足业务规则，所以移入时就不正确； 应用程序中存在的BUG，导致业务规则校验没有被100％地实现； 变化幅度异常的数据 目前系统中存在某些数据满足规则但不合理的现象，如投保年龄超过条款规定的原因，可能是依据业务特批进行的操作。 数据扫描和一致性校验 应用系统后台后台配备有审计程序，定时运行，根据规则搜索异常数据，查找原因并处理。 错误数据清理 目前对错误数据的清理基本是管理员手工执行：如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改。 历史数据卸载 最初的系统设计未考虑这个问题。目前准备将一些表按规则拆分，但需要应用系统中的一些程序调整（比如由于表分拆，原先的查询程序需要作相应的修改），必须统一考虑。 直接后台修改 目前应用系统中的直接后台修改集中在团险领域，由于团险协商情况较多，系统不能接收。处理方法是：由业务做批示，开发人员写脚本，提交运行人员执行，将数据导入； 系统升级和迁移 一般不删除旧表或旧字段。升级时写好脚本，并测试。 江苏应用系统数据维护描述 业务逻辑控制（数据校验） 不允许为空数据的强制录入控制 现有系统对数据录入的控制较严格，目前存在的某些数据字段为空的原因是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入。 业务规则校验 目前存在的业务规则校验问题主要是： 历史数据没有满足业务规则，所以移入时就不正确； 变化幅度异常的数据 目前系统中存在某些数据满足规则但不合理的现象，如投保年龄超过条款规定的原因，可能是依据业务特批进行的操作。 数据扫描和一致性校验 根据业务需求的业务规则不定期搜索异常数据，查找原因并处理。 错误数据清理 目前对错误数据的清理基本是业务手工执行：如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改并备案。 历史数据卸载 部分历史数据如收付费,台帐信息有卸载机制 直接后台修改 业务流程允许的数据修改外数据维护直接后台修改。 系统升级和迁移 一般不删除旧表或旧字段。升级时写好脚本，并测试。 深圳应用系统数据维护描述： 业务逻辑控制（数据校验） 不允许为空数据的强制录入控制 由于我司的核心业务系统Lifepro为新开发系统，设计时对新数据录入的要求相当严格，数据为空将无法继续完成业务流程，并给出错误提示。目前存在的某些数据字段为空的主要原因是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入，或者是在数据迁移时强行对应字段。 业务规则校验 目前存在的业务规则校验问题主要是：历史数据没有完全满足业务规则，迁移时就无法进行严格匹配； 变化幅度异常的数据 虽然对业务数据进行了严格控制，但偶有业务特批现象，这使得目前系统中存在某些数据满足业务规则但不合理的现象。 数据扫描和一致性校验 应用系统后台基本上没有进行数据扫描和一致性校验。 错误数据清理 我司在转换系统时曾经进行过大规模错误数据清理，但是平时基本上没有专门的此项工作。 历史数据卸载 最初的系统设计没有考虑这个问题，有待完善。 直接后台修改 目前核心业务系统中的直接后台修改主要集中在业务反向操作和补入相关记录。处理方法是：由业务人员谢工作单，经过Lotus工作单流转（严格执行层层审批制度），再由开发人员写脚本，提交运行人员执行，完成后台修改； 系统升级和迁移 深圳分公司新开发的核心业务系统Lifepro的数据架构为全新设计，在新系统交接之前，投入大量人力物力进行数据迁移和测试工作。基本方法是先写好数据迁移脚本并执行，再进行数据校验和测试。 现有数据库平台 基本上，目前所有的主要应用系统全部使用Informix作为数据库平台；少量的支持性应用（如网站等）使用MS SQL Server，上海采用DB2作为数据仓库平台。 用户对数据库平台的评价如下图所示： 从上图看到，用户对Informix数据库管理系统的综合评价基本处于可接受的状态，因此可以认为，目前Informix在中国人寿的运行状况较为平稳。 从目前的使用情况来看，Informix存在如下问题： 产品供应商支持能力弱； 从发展的角度看，由于系统不再更新，技术水平和性能都将逐渐落后； 综合上述现状和问题，我们初步认为，将系统迁移到其他数据库平台是必然的趋势，由于目前Informix的运作正常，整个移植计划周期可以根据IBM对Informix的周期来确定，而不必急于立刻实施应用系统的迁移改造。 现有数据访问权限控制 权限管理状况综述 从上述两个统计图可以看出，目前数据库和应用系统的数据访问控制已经可以满足用户的需求，总体的评价较好。并且具备了一些审计功能。 而另一方面，从应用数据的角度，中国人寿缺少一套完整的数据访问审计机制，由于审计和系统效率以及管理工作量之间存在的矛盾平衡关系，因此需要对审计功能进行总体的评估，即从业务风险控制和系统管理的角度，划分需要审计的操作环节，并将其作为应用开发和系统管理的重要组成部分。 CBPS数据访问权限控制描述： 基于应用系统的访问权限 应用系统有独立的权限管理功能 权限的划分一般基于功能进行划分 涉及到客户的一些重要信息控制不是很严，比如帐户信息等。业务上也没有这方面的要求和规定 管理员权限管理 权限管理职责所属部门无统一规定 注重权限的增加，往往忽视操作员岗位变动或离司后权限的更新 审计 无进入，退出系统的日志记录和监控机制 数据访问、修改的轨迹较难追踪 部分数据的产生无时间戳 上海系统数据访问权限控制现状描述： 基于应用系统的访问权限 操作员通过操作系统用户登录，往往使用同一个用户 数据库中设置不同操作系统用户对数据的访问权限，一般所有都放开 操作员登录后直接进入应用系统画面，中断后也直接logout 应用系统中，对各类操作员、各项功能分别设置使用权限 管理员权限管理 应用系统权限设置功能委派专人负责，可能是IT人员，也可能是业务人员 人力资源部负责统一清理岗位权限：整理公司现有员工序号，设置岗位，整理各岗位可以使用的业务系统清单和系统中的功能清单，然后统一设置 审计 某个功能进入和出去的时间和操作员信息有日志记录，对数据实施了哪些操作则无 操作员的增加、销户、对某个功能使用权的增减，这类操作管理部门往往控制不严 江苏系统数据访问权限控制现状描述： 基于应用系统的访问权限 有安全管理功能,提供系统运行各项操作的安全级别设置和管理 特点:可以定义操作员对业务处理系统十一个子系统的操作权限级别，共有1~10共十个级别可以设置不同的操作权限; 各级别之间相对独立，不互相包含 管理员权限管理 应用系统权限设置功能委派专人负责，是业务人员 业务处理中心和财务处理中心负责统一清理岗位权限，设置岗位，整理各岗位可以使用的业务系统清单和系统中的功能清单，然后统一设置 审计 某个功能进入和出去的时间和操作员信息没有日志记录，对数据实施了哪些操作则无 操作员的增加、销户、对某个功能使用权的增减，这类操作管理部门往往控制不严 深圳系统数据访问权限控制描述 基于应用系统的访问权限 前台操作员通过个人帐户和密码登录核心业务系统 数据库中设置不同业务系统用户对数据和业务模块的访问权限，这样用户只能看到已分配的业务模块界面，并使用已分配的系统功能 操作员登录后直接进入应用系统画面，中断后也直接退出系统 管理员权限管理 应用系统权限设置功能委派IT人员专人负责 个人若申请权限，需要通过工作流层层审批后，由IT人员负责设置 审计 当用户使用某个功能或者进行什么操作，其进入和出去的时间和操作员信息有日志记录 有些操作的轨迹没有时间戳和人员记录 差距分析 用户期望的状况 加强业务需求定义的完整性，提高应用系统对业务数据的控制能力； 增强应用系统的维护功能，提高系统维护的自动化程度，减少系统维护工作量； 加强后台数据的访问修改权限控制机制，并不局限于应用系统和数据库系统，还可以通过规章制度来配合管理； 差距及原因 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 改进建议 Action 应用系统的非功能性要求较弱 应用系统的技术设计不足 所有应用系统 将技术设计作为应用开发的重要部分，并在验收时进行严格测试 Informix数据库平台不再进化，难以支撑未来应用 Informix属于将被逐步淘汰的平台 所有基于Informix的应用 向其他数据库平台迁移 信息的权限控制不严谨 注重功能操作权限控制，忽视了数据访问权限的控制 所有应用系统 将信息安全控制和数据保护作为应用系统开发中数据模型设计的一部分工作，信息安全的设计应当以数据访问控制为单位，而不是仅以应用系统功能执行权限为单位； 数据架构评估总结 中国人寿数据架构是一个典型的快速IT建设模式的结果，其主要表现为以迅速实现功能为主要目的，缺乏统一的、有计划的规划，缺乏统一的企业级数据标准； 在业务集成度要求不断提高的压力下，目前数据架构主要的不足就是缺乏整体性，各应用系统间的数据集成度太低； 由于历史原因和应用开发缺乏技术设计，导致数据质量和数据管理都处于较为低水平的阶段，即只能满足局部或暂时的功能需求，而缺乏整体的控制，其结果就是导致数据难以支撑强大的共享、监控、决策功能，影响了业务的运营和发展； 技术基础架构调研与评估 技术基础架构总体现状简述 中国人寿的IT系统经过中国人寿多年来的努力和不断完善，建立了包括总公司，省分公司，地市和县的多层系统架构，承担着中国人寿30多个省的业务需要，IT系统的特点是分布地域广阔，承担的业务压力重，混和异构平台，主机服务器采用了HP、IBM等公司的设备，存储设备采用了HP、IBM、EMC、HDS等公司的设备，网络设备采用品牌有Cisco、3COM、华为、实达等，安全设备则采用了联想的产品。目前中国人寿全国各省数据中心正在陆续实现集中，数据集中第一阶段工作进展顺利，目前只有黑龙江、内蒙古、湖北、江苏、河北等5家公司尚未完成省级数据地域集中工作，未完成的主要原因仍是设备短缺。部分省市实现了逻辑集中， 由于申请迟迟设备不到位，影响整体的集中进程。 目前各省级分公司基本上使用小型机或者PC服务器作为核心业务系统服务器，部分主机设备基本是几年以前的设备。 各省都有自己的一套备份方法，并能坚持定期规律性备份。 公司从1997年起建业务计算机网络，从1998年起建设办公自动化（OA）计算机网络，局域网采用TCP/IP协议，带宽为10M/100M，主要应用于OA、Web发布及业务系统。 部分分公司与银行、邮政实现了网络的互联，以便实现与银行之间的保费结算与代理出单。 网络上基本只是满足连通的基本功能，网络系统从业务发展和期望上都面临着改造的压力。 中国人寿东西部和南北方都存在着明显的差异，各地对基础架构部分的需求和期望也都存在着很大的差异 本章为基础架构部分的评估报告，包括系统架构，业务连续与容灾，信息安全，网络系统，系统管理和数据中心几个部分，对于中国人寿情况的了解信息来源为：总公司IT部门访谈，广西，广东，深圳，江苏，上海，浙江，甘肃，四川8省市访谈，35省市调查表问卷答案，总公司业务部门访谈，领导访谈， 以及项目组沟通等 系统架构 系统架构现状 现有设备情况： 小型机： 全国各省部分采用HP的小型机，如山东，江苏，新疆等， 部分采用IBM小型机，如上海，广西，青岛等 系统架构－图1 资料来源：35省市调查问卷和现场访谈 存储：根据回答的调查表问卷的情况，部分采用IBM （Shark），如上海，广西等， 部分采用HP的XP磁盘阵列，如江苏，新疆等，有些采用EMC的存储。 系统架构－图2 资料来源：35省市调查问卷和现场访谈 PC 服务器： HP IBM 联想 Dell PC机和笔记本： HP IBM 联想 Dell 少部份省份已经做了逻辑集中，大部分省份已经进行了物理集中，物理集中的省份的业务处理服务器在省公司，主机系统的日常管理大部分由各地市各自管理，中，少部分没有集中的省份主机系统在地市运行。 全国各地都有相应的备份方面的规定条例，对业务及管理数据的定期备份、定期恢复测试等方面作了一些规定。 监控备份，早晨复读磁带， 定时做全库全备份 评估分析结果 差距分析的内容 现有不足 根据调查表回答的内容，50％的省已经由于主机服务器的配置和档次已经出现应用运行的性能问题，并对业务的正常运行产生影响。 现有部分主机和存储等是多年以前采购的设备，不能满足业务要求，需要更新或升级 数据交换全部通过局域网由应用程序完成，实时性差，不能满足以后更高的数据实时性的要求。 100％的省认为应该通过系统整合或集中加强资源共享和集中管理和集中备份 部分省完全没有SAN 部分的省数据恢复的过程会超过3个小时，甚至几天时间，超过业务容忍的限度。 系统抽取数据需要锁表，影响到业务正常运行，根本不能满足将来业务扩展数据量增大的要求。 部分省没有规律性的进行恢复测试， 有些省从来没有进行过恢复测试。 系统架构－图3 系统架构－图4 资料来源：35省市调查表问卷和现场访谈 可以看到没有完善的恢复策略和恢复测试方法的占19％，从来没有做过恢复测试的省份占74％，其他的占3％ 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 系统构架应是可靠的、可扩展的 设计建立统一的更加完善、高效的系统架构 加强SAN建设，增加在线备份的设备及系统 非常关注集中备份 热备系统及高效的备份恢复策略 关键业务在处理、维护、冗余、备份方面，全面自动化实现，做到简洁、迅速 已经向总公司申请的设备要尽快就位 系统架构－图6 资料来源：35省市调查表问卷和现场访谈 差距与威胁 难以共享，各个系统间存在着严重的信息孤岛现象 服务器与存储――大多是计算机直连，SAN的程度不够，缺乏资源共享的条件和基础。 缺乏系统的集中管理控制能力 缺少群集结构 没有双机热备份，欠缺系统的有效性，会导致系统系统故障时无法保障业务运行 欠缺需求设备的统一的指标和方法。如业务的哪些指标属于贡献大的指标，决定硬件投资规模，什么规模的业务需要什么规模什么配置的设备，用数字方式反应出来，没有标准，导致设备申请没有统一的路径和依据。 丢失数据 缺乏成熟的在线备份的手段，在生产时间不能进行有效的备份，造成 系统突然 系统发生故障时会丢失数据，无法恢复 恢复时间太长 恢复时间太长，可能会严重影响到业务的正常运行 缺乏备份恢复流程与手段 缺乏成熟的恢复策略和技术手段 ，没有成熟的在线备份的流程和恢复流程 耗费人力资源 耗费人力资源，备份自动化程度低 恢复成功的可能性 全凭感觉，恢复成功的可能性低，出错概率大 根本原因 设备不到位 没有备份恢复测试环境 没有意识到重要性和紧迫性 受集中进度的影响 差距分析总结 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 各个系统之间相互独立，难以共享，存在孤岛 设备不到位 受集中进度的影响 不同应用之间 的数据共享 增强系统共享数据的能力和灵活性，在系统设计时充分考虑数据共享的能力 在系统架构的设计和调整中采用SAN结构，并增加SAN集中统一管理 主机系统缺少冗余备份和热切换 没有意识到重要性和紧迫性 设备不到位 所有应用系统的主机 增加设备，增加与业务主机系统相匹配的设备用于冗余和热切换 增加热切换软件 设置群集系统 备份恢复流程缺乏 没有备份恢复测试环境 没有意识到重要性和紧迫性 所有需要备份关键业务数据 增加备份恢复测试环境 增加备份恢复流程 经验参考 HP公司推荐的系统架构－存储架构及其考虑的因素 HP公司建议的SAN架构 降低总体拥有成本 促进服务水平 提高服务器/存储利用率和性能 有利于标准化 加强备份恢复能力 有利于系统移植 有利于数据整合 HP公司推荐的系统架构－备份恢复目标与策略 集中备份恢复保障数据的最大保护 高可用 –备份恢复一定保证数据的有效性 零停机 – 在备份期间必须保障对关业务的数据资源的连续的可存取操作 零影响 – 备份过程中必须保障关键业务的性能不降低，不影响业务正常操作。 快速恢复－数据丢失时的快速恢复 降低TCO－完全自动化，跨平台 Helvetia Patria Group集团 瑞士最大的保险公司之一，服务于六个国家，11家子公司，5000名员工 生产系统，备用系统，测试系统 均衡负载 群集系统 集中备份 多台高性能服务器 互联网统一出口 VPN技术 平安保险 开放、安全的集中SAN结构 SAN智能的管理系统 SAN环境下的集中数据备份 实现零停机时间的备份和恢复 自动备份 由于采用了先进的磁带库、磁带机和备份介质管理，重要数据的安全性、可靠性和可管理性得到了保证。 备份管理系统有灵活良好的扩展性，能够满足信息系统随着平安保险公司的飞速发展不断扩充和升级的需求。 资料来源：惠普咨询内部网站知识库 业务连续与容灾 业务连续与容灾现状 据调查表中的“您认为对于目前可能造成系统长时间中断而对业务造成严重影响的灾难或事件是？“一题反映的结果，大部分公司认为服务器故障、网络故障是可能造成系统长时间中断的最主要威胁，然后面临的是存储故障、介质故障、大厦电源故障、火灾、水灾、大面积停电等威胁 18个省会把磁带在备份第二天放到几公里以外的银行或其他地方，7省没有做到这点 允许业务停顿不能超过半天的省26个, 另外一两个省可以容忍1－2天 不能容忍长时间业务停机 评估分析结果 现有不足 面对可能的存储故障，介质故障，大厦电源故障，火灾，水灾，大面积停电，地震的威胁，没有应对措施 26省没有做过风险评估和业务影响分析，所有的省都没有做过正式的业务影响分析 发生灾难后无准备好可行的替代方案，如主机替代，存储替代等应急措施 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 不能容忍长时间业务停机 希望各种突发事件造成业务停机要在半天之内，其中部分省要求在一两个小时之内 不希望各种突发事件造成严重影响业务 大部分省非常关注容灾和数据安全 业务连续与容灾－图1 资料来源：35省市调查表问卷和现场访谈 差距与威胁 发生局部灾难时可能会丢至少一天的数据，无法弥补， 严重影响业务，若磁带坏，丢失更多的数据，造成更严重的问题 若区域或大面积灾难，丢失全部数据，业务不能接受 严重灾难后经过的准备工作，如借机器找环境，机房电源等需要很长时间，再加上安装调试可能需要半个月到一个月才能恢复到以前的数据，丢失一段时间数据，但如果某个磁带故障，则所有数据不能恢复。恢复过程与时间取决于借用系统或者紧急采购的时间，建立环境的时间。这对于正常恢复业务是极大风险。 在出现灾难情况时，没有经过测试的紧急计划，以及应急措施，没有恢复流程以保证关键应用的连续性，从来没有进行过预演和测试，一旦灾难发生，会引起混乱。 发生问题将会凭感觉临时沟通， 为保障业务的连续性带来风险。 虽然大多数公司认识到风险的存在，但做过业务影响分析（Business Impact Analysis）和风险评估分析的公司却只有一两家 发生灾难后没有准备好可行的替代方案 现在的状态出现灾难，业务很长时间不能恢复，不能满足业务要求 根本原因 侥幸心里，灾难是小概率事件，没有发生过 没有谁真正考虑过发生灾难后的损失和影响 没有恢复测试环境 没有测试设备 没有紧迫感 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 没有保障业务连续的流程 侥幸心里，灾难是小概率事 所有的业务 加强业务连续的流程的建立，规章制度的建立和实行，保障业务的连续性 若发生灾难，丢失数据，业务停顿 侥幸心里，灾难是小概率事件，没有发生过 所有业务和应用 改善在线备份的能力， 特别是异地备份的能力 对于突然发生的情况没有应急措施 侥幸心里，灾难是小概率事件，没有发生过 所有的业务 与厂家讨论比如发生灾难时的设备替代方案，或者人寿内部确定设备替代可行性方案 若发生大面积灾难，丢失数据 侥幸心里，灾难是小概率事件，没有发生过 所有的业务 容灾系统的建设提上日程，并且付诸实施 经验参考 HP公司参照标准的业务连续与灾备建议 企业业务面临的风险 IT服务中断可能对企业业务产生的影响 业务连续性的流程并入企业处理流程和结构 紧急状况的紧急恢复流程 员工培训 制定业务连续的执行计划的每部分的人员职责以及备用人选 灾备技术解决方案的实现 测试与预演计划 变更与更新计划 资料来源：惠普咨询内部网站知识库 American United Life 数据中心运行7×24小时 解决故障或灾难时的业务中断，保障快速恢复和业务连续运行 最大限度的IT正常运行 快速恢复 详细的业务恢复计划 在另一地点热切换 预演100％达到目标 严格的测试方法和过程 YODOBASHI CAMERA YODOBASHI CAMERA是日本东京最大的家电销售大型连锁店 17家连锁点 2200人员工 灾难发生导致业务中断意味着上百亿日元（10 Billiion）的收入 YODOBASHI CAMERA的容灾架构见下图 YODOBASHI CAMERA的业务连续流程 制定每天的工作流程 灾难紧急流程 切换流程 预演 容灾流程员工培训 平安保险 为了保障最大限度地满足平安保险系统业务长久运行的要求，平安保险公司现在配置了一套灾备系统，包括光纤存储系统， 专门用于存放系统业务数据。利用操作系统逻辑卷管理功能，可将原数据中心的业务数据镜像到冗余的灾备中心的存储系统中，从而保证了存储数据的高可用性 平安保险正在考虑数据中心下一步集中到上海、深圳，并且上海深圳两个数据中心会成为两个互为备份的灾备中心 信息安全 信息安全现状 随着公司的数据集中和业务的发展，安全问题越来越成为公司当前急需解决的一个重要问题，这一点从调查表中得到了充分的反映。在基础架构调查表中的“以您的观点，什么是您公司的关于网络服务的最主要的挑战”一题中，100%的被调查人员选择了安全问题这一项。 大部分省市认识到安全比较重要 ，制定了一定的安全措施 2002年在全国范围内安装推广了联想的网御防火墙 很多分公司构建了一定的信息安全策略，并这些策略写成了书面文档，同时根据情况的变化对安全策略进行审查和更新。很多公司对安全工作做到了责任落实到人，并定期检查安全策略的落实情况 对每一项IT资产，大部分的公司都有专人做文档记录，并由领用人或其他相关人员负责保护 对于口令管理的这个问题，各分公司也都有一些相应的规章制度和办法，比如安徽对口令实行专人专管（主要指管理员），定期更换 由于病毒造成的危害越来越大，防病毒工作现在已变成一项很重要的信息安全任务。总公司推广了KILL防病毒系统，该系统分为服务器端和客户端，客户端在做一些简单设置后就能够自动升级病毒特征码 为了实现省级数据集中，各分公司在省级数据中心建设的时候，对数据中心的物理安全，比如火、水、电源、门禁等的安全都作了很多的工作，在这一点上已比原先的地市级数据中心完善了很多 为了提高网络的性能和安全性，很多省公司的内部局域网划分了多个vlan，通过这种方式可把业务处理网络和办公网络逻辑上分开，并可以在它们之间加上访问控制列表（Access Control List）以控制办公网络对服务器区的访问。这样可以方便安全管理，减少广播数据包的流量 评估分析结果 现有不足 没有完善的整体安全策略 绝大部分的公司都没有系统监控措施，这个从调查表问卷问题“是否使用了实时的系统监控措施？ 例如监控正在进行的对系统的攻击，系统和网络的可用性等。”的回答中可以明显看出来，只有深圳一家公司有这类措施。同样，在问题“系统进行过渗透测试(为了证明网络防御按照预期计划正常运行而提供的一种机制)吗？”一题中，也只有湖南一家公司说他们做过这样的测试。 部分分公司的业务网和办公网没有逻辑分开，同时也没有相应的隔离措施。 办公网上internet的需求很迫切，禁止上互联网带来很多不便，在调查表问卷中，对于办公机器的拨号上internet问题，选“禁止拨号”的公司有20家，选“规定拨号时取下内部网线”的公司有7家，选“没有限制”的公司有陕西，重庆两家。而据掌握的情况来看，很多公司在只架设防火墙而没有物理隔离情况下就把internet接入到公司内部网络。对于如何在保证网络安全的同时，也满足公司办公用户的上网需求是该说是我们应该尽快解决的一个问题。 目前中国人寿安全与业务发展对网络需求之间有一定的矛盾一直没有解决，比如有些大客户提出要在internet上查询自己的保单情况，而公司从安全的角度又不能让用户通过internet接入到公司的业务数据网中。 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 建立严格按IT行业公认的安全体系和安全标准，制定统一的安全策略 以安全技术为手段，注重全体员工安全意识的培养 增加投入，加大培训力度，提高管理水平 建立安全有效的系统 有制度保证的前提下，充分发挥技术手段的作用 希望多推广一些有关安全的监控软件和管理软件，加强自动跟踪与监控功能。比如有一套比较实用的软件系统保证信息系统的安全 提高网络安全防止非法入侵, 增强网络的可靠性和安全性。省公司数据中心必须安装防火墙，以便在与外部网络互连时保护网络安全 实现实时系统监控，有效防范非法攻击 制定安全措施在有效保证核心数据安全的同时不会成为系统运行效率的瓶颈 出台一套安全运行的可操作手册 差距与威胁 在这一评估阶段，确认了可能对目标系统和资产造成损害的威胁以及差距 缺乏完善的整体安全策略，造成信息安全没有系统性的流程、规章制度和统一的策略 缺乏安全管理框架，使得信息安全没有整体的安全框架和系统的安全体系 缺乏完善的安全组织负责审批IT安全策略、分工并全面协调IT安全措施的实施， 规律性的审查安全策略和责任、监控问题和危险、批准加强信息安全的活动 ，包括了除上海外的所有省 没有规律性的信息安全评估措施，制度和方法 没有专门的信息安全专家来协助解决安全问题和作安全影响评估，比如 对于合作伙伴访问公司信息资源评估过风险，对于新增加的所有的IT设备和服务，100％没有专门的授权流程对带来的安全影响进行检查，对于信息系统的安全存在隐患 我们发现由于缺乏完善的安全策略和正式的管理方法，可能在员工操作方面存在潜在的威胁。离开安全策略和管理方法的指导，会导致员工缺乏安全意识或者忽略安全问题 缺乏入侵检测工具和故障管理流程，存在着严重的安全隐患 缺少正式的安全管理流程，比如缺少定期检查安全事件报告并根据教训进行安全管理方面的决策，没有关于公司销毁数据，设备，软件正式的流程，包括山东，广东， 缺乏新加入人员和离职人员的用户管理流程。比如IT人员直接在数据库修改数据的想象仍然存在，存在着安全隐患 没有实时监控对系统的攻击，没有进行过正式的渗透测试，无法面对外界的有意无意的入侵和攻击 如果说internet接入是来自外部的安全隐患，那么很多公司现在内部也有很大的安全隐患，他们的数据中心与地市网络及办公网络没有做任何的防范措施。其实内部人员在这种情况下带来的安全隐患比外界带来的大得多 互联网问题没有解决好，禁止上互联网，有的分公司上网时需要拔内部网线，存在着管理不严的现象和审查制度不严以及意识不够，实际上隐含着隐患 根本原因 由于不是关键业务，内心里安全认识不够 对信息安全问题的损失估计不足 没有太重视，没有急迫感 有时为了迁就业务部门，比如直接修改数据库等 系统分散在地市，造成对数据库的操作权限都有没有统一的规定，素质不等，都是产生安全问题的隐患 差距分析总结 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 没有整体的安全策略和安全管理体系 由于不是关键业务，内心里安全认识不够 对信息安全问题的损失估计不足 公司的所有信息资产 整个公司需要定义统一的安全体系，策略与管理方法 没有专门的组织进行信息安全方面的管理和风险评估 由于不是关键业务，内心里安全认识不够 对信息安全问题的损失估计不足 公司的所有信息资产和组织 专门的组织责任明确来负责安全管理 互联网的互连和检测 对信息安全问题的损失估计不足 公司的保密数据 现有防火墙的功能充分利用，重新审视现有防火墙设置，结合信息系统环境 风险评估策略 对信息安全问题的损失估计不足 公司的保密数据 对于风险评估形成制度化和规律化 经验参考 现行的国际信息安全管理体系标准包括BS 7799（ISO 17799） 等。 ISO/IEC17799包含了100多个安全策略来协助企业识别在运作过程中的信息安全，可以分成以下几个方面： 安全政策 组织安全 资产的分类与控制 人员安全 物理和环境的安全 通信和操作管理 访问控制 开发和维护 业务持续性管理 符合性 资料来源：ISO17799国际标准 全球最大的再保险公司德国[慕尼黑再保险公司] 保护慕尼黑再的信息安全免受危险的威胁 创建并实施全球安全策略 创建新的组织来推广，管理并维护策略，形成有效的安全管理体系 执行全球安全架构 培训员工适应新的安全规则通过改变行为来更好实现保护企业信息安全的目的 实现E－Commerce 由于信息安全不只是IT部门的事，整个企业都会发生些变化，项目分三个阶段： 第一阶段：制定安全策略并得到高层批准 由厂家和慕尼黑再组成专题组 访谈，检查现有文档 第二阶段：建立全球的组织来执行安全策略 慕尼黑再建立一个专门的信息安全办事处组织来监督管理实施安全策略。 制定严谨的方法和推广策略，各个区域并行，不论发达程度 第三阶段：从普通员工到高层管理层培训改变行为 从高层管理层到ISO，IT经理，严格参加培训 为各地高层专门的培训 各地的员工根据各地环境文化的不同采用多样化的培训方式 网络架构 网络架构现状 网络系统现状 网络设备情况 在公司现有的网络设备当中，路由器和交换机很大一部分采用了Cisco的产品，尤其是核心网络设备。另外，在一些最近对网络加以改造的公司中，大部分公司采用了Cisco的产品，这一点与今后的呼叫中心要采用Cisco的IPCC产品有很大的关系。剩余的品牌包括3COM、华为、实达等。根据现有资料统计，全国除了福建、甘肃、安徽、天津以外全部采用Cisco的产品作为核心交换机，而在核心路由器方面，除了甘肃、安徽、天津、海南、厦门、云南、福建几个省之外其他的地区也都选用了Cisco的产品。3COM是在网络建设初期大量采用的设备，由于3COM公司自己的特殊原因，现在3COM的产品已处于淘汰被替换的阶段。而华为、实达的产品是为了降低成本，作为非核心网络设备使用的。以下是全国核心网络设备品牌分布图 网络架构图－1 网络架构图－2 资料来源：35省市调查表问卷和现场访谈 就作为核心网络设备的Cisco产品的具体型号来说，大部分省级中心路由器采用Cisco 7500系列或7200 系列，而核心交换机采用catalyst 6500系列或catalyst 4000系列。其中以7500系列作为核心路由器公司有12家，有意向选用7500系列的有7家。选用7200系列作为核心路由器公司有5家，选用3600系列作为核心路由器公司有7家。 就全国来说，省公司到地区公司一般是2M带宽的线路。地市与县之间一般为128k或64k线路，但有些东部发达地方在地市与县之间也采用了2M的线路，另外中西部也有这种情况，比如四川的有些地市在与网络运营商作价格协商后，地区到县也是采用了2M线路。今后随着业务需求的发展和网络资费的不断下调，网络带宽会不断的提高。 评估分析结果 现有不足 网络没有工具与监控手段，影响到业务效率 Internet接入非常不方便 现有的网络功能简单，只是局限于物理连通，层次低 全国的IP地址分配基本沿用96年的地址规划，不能适应以后系统互连互通的要求 现在业务的发展为网络提出了一些新的问题。比如服务延伸的问题现有网络实现不足 网络设备和线路存在单点故障。网络线路的备份在全国也是很不相同。大多数的地区由于资金的问题，网络线路的工作基本没有开展。虽然有的地区有PSTN形式的备份线路，但这一线路在线路出现故障时很有可能起不了什么作用 银行邮政等中介的互联没有完全互联互通，只有少数省份与工行互联，需要加强 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 将公司的办公网络、业务网络隔离，实现INTERNET连接 骨干网络要稳定高效，更高的可靠性,易于扩展,良好的备份线路 明显的分层（核心层、分布层、接入层），能隔离故障 提供更多的用户接入渠道，如基于Web的PC、移动电话、传真和电子邮件等 在保证业务系统安全的基础上，更多的提供提供增值服务，提升竞争力 提供对于网络服务提供商进行服务质量检测的手段和方法 现在各地区的internet接入需求很强烈 现有的网络功能简单，只是基于连通，需扩充网络功能需做较大调整 差距与威胁 没有专门网络评估效率问题，对于网络的使用率、利用率，关键业务所占的网络资源需求有些模糊不清，欠缺组织或者活动来专门评估网络资源情况 现有的网络功能过于简单，基本上只是基于连通的功能，没有充分利用现有的资源，从增值服务等方面提供支持与服务。需扩充网络功能，提高网络的增值服务能力 没有充分利用国际互联网的优势与优点为中国人寿的企业和业务发展服务，强制规定不能访问互联网，关注互联网的安全问题重于利用互联网的优点。 关于使用互联网的需求可以两个方面的需求来理解，管理的和业务的两方面的需求。管理的需求包括办公、网上银行等，而业务方面的需求则是让用户通过internet查询自己的投保信息等，比如通过web网站的方式。 有些地方建立网站供用户查询时，他们向查询服务器传送数据是通过手工拔插网线或通过磁带手工倒数据的方式来实现的。这些方式通过手工操作来实现的，不但较为麻烦，而且实时性很难保证 中国人寿网络系统从网络设备到网络线路都存在单点故障。虽然故障发生概率大小不一，但一旦发生网络设备或线路故障，将会影响对应用系统的访问和处理，影响到业务的正常运行。 虽然有的地区有PSTN形式的备份线路，但这一线路在线路出现故障时很有可能起不了什么作用，特别是对于发达地区，也没有对网络备份给予足够的重视 根本原因 各地领导没有把网络系统当成一种服务，没有把网络具有一种前瞻性的和能够主动为业务提供各种增值服务的系统 各地对网络的要求集中在基本的连通上 网络系统技术人员疲于应付，分公司网络系统的工作基本处于救火的地位 领导关注不够，只要网络不出大问题，只要网络能够维持运转，信息技术部门的领导的关注点也往往不在这里 就像有人说的一样：每年评先进都是改数据的，别的部门的人都不认识网络管理员，只有在网络不通的时候，才想起来问网管在哪里 网络系统不足的造成原因部分是因为资金问题，人的观念和认识却是更深层次的原因 差距分析总结 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 现有的网络功能过于简单，基本上只是基于连通的功能 各地领导没有把网络系统当成一种服务，没有把网络具有一种前瞻性的和能够主动为业务提供各种增值服务的系统 各地对网络的要求集中在基本的连通上面 公司的全部网络架构 电子商务功能的建设以及其他增值服务的设立 对于网络的使用率、利用率，关键业务所占的网络资源需求有些模糊不清，组织或者活动来专门评估网络资源情况 分公司网络系统的工作基本处于救火的地位 公司的广域网链路带宽 专门的手段和组织来定期评估网络资源情况 与互联网的互连不完善 对网络的要求集中在基本的连通上面 公司的网络架构与互连 解决访问互联网的技术手段，比如评估VPN的使用等 采用96年的IP地址 网络系统技术人员疲于应付满足业务基本需求压力 分公司网络系统的工作基本处于救火的地位 公司的所有主机路由器交换机 IP地址的重新设计和改进，并注意分步骤进行和计划性 经验参考 就国际先进经验来看，基于TCP/IP协议的网络架构应具备高可用性、高可靠性、高安全性、可管理性、标准化、可扩展等特点。 高可用性 高可靠性 高安全性 可管理性 标准化 可扩展性 平安保险的广域网解决方案 随着平安保险公司的发展，平安保险公司的数据网络发展迅速，已经形成了覆盖全国各个办事机构的规模庞大的数据网络系统。其广域网以深圳为核心，分为北京、上 海两大管理中心区，深圳、北京、上海三大中心分别以高速DDN线路互相连接，构成三角形的广域网络骨干。平安保险公司其他分支机构（二级机构）就近连接到深圳、北 京、上海三个中心。各中心之间通过高速线路连接，形成一个环状网络拓扑结构，以动态路由实现核心层节点间的线路备份，同时，网络中心之间通过卫星对DDN进行备份以电脑中心为区域网络中心，各二级机构电脑网络就近接入附近的区域网络中心；三（四）级机构电脑网络直接连入所属二级公司（网络结构见图一）；三、四级机构通过PSTN号实现与二级机构之间的线路备份，以保证网络的稳定性。深圳总部提供Internet 接入，对外提供网上服务。整个广域互连网络是一个树形层次状网络，连通600多个分支机构。业务数据分散在各分支机构，由分支机构定期将数据汇总到深圳总部的数据中心。平安保险公司整个广域网络系统，由骨干网（深圳、北京、上海）、分布层（二级机构，几十个）、接入层（三级机构，几百个）三层结构组成。 网络建设与运行维护管理工作由总公司统一进行。分支机构新增连网点需经总公司审批，由总公司设计方案和配置参数。网络运行维护由网络中心处理，为提高维护能力和水平，在总公司网络中心和华北网络中心配备了运行Cisco 网管软件的网管系统，对网络设备的故障、性能、配置、流量、安全进行监控管理。 系统管理 系统管理现状 针对中国人寿全系统反馈调查结果的进行的统计分析表明：仅有%省分公司对目前系统管理持基本满意的态度，另有%的省分公司对目前系统管理的功能和效果表示不满意。有4%的被访单位表明最近准备实施新的的系统管理项目且能满足系统要求，有12%被访单位表明最近准备实施新的的系统管理项目但不能满足系统的要求，另有84%的被访单位表明最近没有准备实施新的的系统管理项目的计划。在回答的如果上新的管理系统，是否有合适的系统管理流程支持？这个问题时，%的受访单位回答没有，有%回答有。 在中国人寿全系统中除深圳、新疆、吉林等少数分公司使用OPENVIEW（深圳）和CISCOWORKS2000（新疆）外，其他省分公司目前在做系统管理工作时采用的主要技术手段有：主要靠手工监控(人工随机监控)，依靠人工对每台设备进行定时监控,只有在出现问题的时候管理员才能发现问题；通过各种单一的命令来实现系统监控管理；利用操作系统本身带的一些工具进行管理；定岗定人，全部依靠人力，由专门的系统管理人员进行管理；部分监控可以用SHELL来实现（如每日备份的检查）。 系统管理图－1 系统管理图－2 系统管理图－3 资料来源：35省市调查表问卷和现场访谈 评估分析结果 现有不足 大部分的公司对于系统管理现状不满意，没有成熟的系统管理软件 手工管理无法累积历史数据进行运行状况分析。这种原始方式效率太低 没有日志记录，不利用监控，查找问题。不全面且繁琐，不够直观、综合、全面 需要增加人员的严格管理，对人的依赖性非常高。如果上专门的系统，又有可能增加操作的复杂性 有在出现问题的时候管理员才能发现问题，并着手解决，无法对问题进行预测 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 现有的管理办法效率不高，希望提高管理效率 加强系统管理的功能 希望将来的管理系统对中心的所有设备进行智能监控，具有完善的系统管理流程 改变目前在系统管理方面目的单一、不系统，不完善的现状 在规范操作流程及文档化方面有待改进，同时需要总公司的可操作性指引 希望总公司在采购系统管理软件考虑各地经济发展的不平衡性 系统管理应具备定时查找、升级功能 需要增加专门的管理系统，同时希望不要带来太大的复杂性 差距与威胁 没有一套成熟的管理流程和规章制度来对中国人寿的整个IT系统进行统一的管理，欠缺成熟的系统管理体系，各自按照自己的习惯去管理各自的系统，没有整体性和统一性 各地都缺乏完善的系统管理制度和管理流程，疲于应付，被动管理，没有主动的去为业务服务 管理方式更多靠手工，太原始，没有与中国人寿IT系统规模和业务发展速度相匹配，也不利于标准化作业。 缺乏成熟的系统管理软件和工具，靠手工，经验，凭感觉，管理方式比较初级，无法对问题进行预测，无法对问题进行有效地分析 系统管理方式对人的依赖性非常高，效率太低，浪费很多的人力资源，自动化程度太低 根本原因 系统管理的意识不强，当成锦上添花的工作 不受领导重视，系统管理不会对业务产生直接影响，只是IT部门的事情，领导的关注点不在这里 申请产品困难，产品采购流程慢 没有紧迫感 差距分析总结 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 管理方式更多靠手工，太原始，没有与中国人寿IT系统规模和业务发展速度相匹配 申请技术产品困难，产品采购流程慢 公司的所有IT系统包括主机系统，网络系统 申请的系统管理软件尽快就位，利用自动化和流程代替靠经验和感觉，提高人力资源的效率 没有一套成熟的管理流程和规章制度来对中国人寿的整个IT系统进行统一的管理，欠缺成熟的系统管理体系，各自按照自己的习惯去管理各自的系统，没有整体性和统一性 不受领导重视，系统管理不会对业务产生直接影响，只是IT部门的事情，领导的关注点不在这里 公司的IT部门 领导意识到系统管理流程的重要性，建立系统管理流程 经验参考 HP公司建议的系统管理： 系统管理系统应该以IT服务管理为核心建立管理信息系统体系架构。该信息 系统构架除包括传统的网络、系统及数据库等管理层面外，还应包括相对独 立的服务管理功能层。 系统管理系统应该传统的技术层面和ITSM的流程管 理相结合，建立健全依托于IT服务管理信息系统体架构的支撑系统管理流 程。系统管理系统主要包括以下技术和管理流程的建设： 配置管理 故障管理 性能管理 安全管理 记帐管理 除了以上的功能外，有些系统管理还包含一些额外的功能。如：系统防病毒、软件电子分发、远程控制、控制台（及分级，分功能控制台）、DESKTOP资产信息管理、各种应用管理等。目前，使用较多的有系统管理软件：CA Unicenter, IBM TIVOLI TME, HP Open View、NetIQ AppManager 等。 资料来源：惠普咨询内部网站知识库 数据中心 数据中心现状 全国数据集中第一阶段工作进展顺利，绝大部分省份已经完成了地域的集中，其中少部分已经完成了逻辑集中，目前只有黑龙江、内蒙古、湖北、江苏、河北等5家公司尚未完成省级数据地域集中工作，申请设备迟迟不到位影响了数据集中的进程。 全国的很大部分省级数据中心建设基本都还处于初级阶段，尤其是那些正在进行数据集中的省级数据中心。很多省级数据中心为集中购置的设备没有到位，只是把地区数据中心的原有机器搬到了省公司的机房。依靠现有主机设备实现数据及业务的逻辑整合几乎不可能实现。 在调查表中的“您的数据中心要求是24×7的吗？”一题中，共有25家公司的数据中心要求是24×7的。除此之外，大连、甘肃（省公司）、宁夏的数据中心要求是7×12，只有青海说他的要求是5×8。 评估分析结果 现有不足 100％的省没有形成整个数据中心基础架构的全共享架构，导致不同的应用之间只能通过应用程序之间传送共享信息与数据，信息资源共享不足，耗费大量时间，人力资源，数据实时性差 数据中心要求7×24的86％,7×12的11％（有三家），现状不满足 用户期望 通过对各级业务部门IT部门和各级领导的访谈，以及全国各省问卷调查，我们总结用户期望如下： 希望加强资源共享 需要有效及稳定的系统整合 数据进一步集中 增加SAN管理 系统管理图－1 资料来源：35省市调查表问卷和现场访谈 差距与威胁 严重的信息孤岛现象 数据中心没有达到24×7的要求 数据中心的集中整合没有统一的指导计划和详细的步骤与方法 根本原因 缺少统一的数据中心集中过程详细规划 省数据中心集中进展太慢 集中的进度安排强调不够 各地实际情况不同，业务需求不同，在集中过程中所用应用系统遇到问题，导致对集中看法不一和积极性问题 设备采购效率太低，影响数据集中进度 编号 ID 观察 Observation 根本原因 Root Cause 影响范围 Impact 初步建议 Action 严重的信息孤岛现象 IT孤岛，没有使IT能力有效共享 数据中心集中太慢 设备采购效率太低，影响数据集中进度 各地实际情况不同，业务需求不同，在集中过程中所用应用系统遇到问题，导致对集中看法不一和积极性问题 公司的所有IT系统包括主机系统，网络系统 加快数据集中的进度，增强系统共享 数据的能力和灵活性，在数据中心设计时充分考虑数据共享的能力，在系统架构的设计和调整中采用SAN结构，并增加SAN集中统一管理 数据中心的集中整合缺乏统一的指导和详细的步骤与方法 对于数据中心集中整合的步骤与方法重视不够 公司所有正在和尚未集中整合的数据中心 数据中心的集中整合过程需要细化并且尽量统一，解决集中过程中需求和应用出现的问题 经验参考 HP公司建议的数据中心整合内容 调研 压力测试 网络规划 应用系统规划 实验点迁移 全系统整合迁移 HP公司建议的数据中心整合步骤 Wachovia是美国第四大银行，拥有10万员工和数千个营业网点 提高基础架构适应性：灵活性，有效性，可利用性，业务连续性，高效性 提高服务级别和客户满意度 降低IT支持成本 缩短产品推向市场的时间 高层达成共识，极力支持 IT部门，业务部门与厂家密切配合 制定蓝图 统一的详细的移植计划 详细的测试计划和过程 资料来源：惠普咨询内部网站知识库 基础架构评估总结 基础架构的评估报告，是经过8省市访谈，35省市调查表问卷答案，总公司业务部门与IT部门访谈，领导访谈，以及项目组的沟通等，中国人寿IT系统总体的特点是承受的业务压力大，IT系统分布地域广，异构平台如采用了不同平台的主机服务器、存储设备和网络设备。从中国人寿IT基础架构总体来看还是处于比较初级的水平，与业务需求和先进经验相比有比较大的差距，主要集中表现在以下方面：系统架构方面系统资源难以共享，各个系统间存在着严重的信息孤岛现象，欠缺评测业务系统对设备需求的合理的方法和依据，以及欠缺备份恢复流程和备份恢复手段的完善。在业务连续与容灾方面，基本上没有任何流程和方法来从容应对灾难，与中国人寿500强的地位和业务发展的需求不相匹配。在信息安全和网络系统方面，没有整体的安全策略和安全架构体系，缺乏防范攻击的在线实时检测措施和专门的组织进行信息安全方面的管理和风险评估，现有的网络功能过于简单，基本上只是基于连通的功能，需要加强网络的增值服务，并利用有利条件更好的为客户服务。管理方式更多靠手工，太原始，缺少系统管理流程和技术手段。数据中心的集中整合缺乏统一的指导和详细的步骤与方法。差距的根本原因主要集中表现在申请的设备迟迟不到位，影响到系统共享结构改造和数据中心集中。对于小概率发生的风险，内心里认识严重不足，疲于应付和迁就业务部门，没有意识到重要性和紧迫性。 IT治理调研与评估 IT治理总体框架 信息化是中国人寿保险公司发展的最重要的推动力。经过股改后的股份公司已经将IT作为核心竞争力作为实现业务目标的发展战略。IT系统正在从传统的后台支持转变为业务发展的直接驱动力。中国人寿整个企业对IT的依赖程度非常大。随IT而来的风险、利益和机会使得IT治理成为中国人寿信息化发展中很关键的一个方面。管理层需要确保IT与公司战略一致而且公司战略很好地利用IT的优势。IT治理对于中国人寿业务目标的实现起着至关重要的作用。 IT治理概念 信息系统审计与控制协会（ISACA）对IT治理的定义为：IT治理是一个由关系和过程所构成的体制，用于指导和控制企业，通过平衡信息技术与过程的风险、增加价值来确保实现企业的目标。 IT治理主要包含以下一些关键点： IT治理与企业战略目标是一致的； IT治理管理执行人员和管理者的责任； IT治理指导和控制IT投资和机遇； IT治理包括组织人员管理、流程和技术实现，确保IT支撑和扩展公司的战略目标； IT治理充分合理利用公司的信息资源，有效地集成与协调； 确保IT及时按照目标交付，支撑业务价值的传递； 引导IT投资平衡，支持业务增长和竞争优势； IT治理的目标 IT治理的目标主要包括： 与业务战略目标一致； IT治理来源于业务发展目标和IT发展战略，通过IT治理的手段，实现信息技术对业务目标的支持； 有效利用信息资源； 通过IT治理对信息资源的管理职责进行有效管理，保证投资收益。 风险控制与管理； IT治理通过对关键IT资源的有效监控和管理，降低IT的风险和对业务产生的影响，从而实现降低业务的风险。 IT治理的架构 IT治理的架构： 企业设立IT发展目标，通过IT管理来保证目标的实现，这些目标中渗透着企业的IT发展方向，指导企业活动和使用资源，IT活动的结果被衡量和报告，为输入提供不断的修正和维护控制，从而开始下一轮循环。 IT治理的组成部分包括管理、流程、组织、资源和投资几个方面，这几个方面的内容形成有机的整体――IT治理，成为实现IT战略目标的手段。 管理：一般项目管理、系统开发管理、系统测试、软件部署管理、外部资源利用等； 流程：IT服务管理流程； 组织：IT组织架构、职责权限划分； 资源：人力资源，设备等； 投资：IT预算、成本等； IT治理成熟度模型 上述为IT治理成熟度模型，企业可根据相应的指标确定自己的等级，从而了解自身境界，分析出差距。 0. 不存在 完全不存在可辨识的IT治理流程。 初始级 企业已意识到存在IT治理问题并需要研究，尚无标准流程。治理方法混乱，但对于问题和研究方法有零星的、不一致的交流。 可重复级 人们普遍对IT治理问题有所了解，IT治理行为和效果处于未发展阶段，包括IT计划、交付和监控流程。选定了IT流程，以提高及控制企业核心流程，并且作为一种投资得到有效的治理，进而形成明确的IT架构。 已定义级 人们理解并接受IT治理。流程被标准化、形成文档和实施，管理与标准流程相一致，开始了非正式的培训，对全部IT治理行为的表现进行记录、跟踪，促进企业整体提高。 已管理级 通过正规培训，各个层次全面理解了IT治理。人们清楚地知道谁是顾客，而且通过服务水平协议，来定义和监督相应的责任。责任清楚，也落实到流程中的具体人员。IT流程与业务密切相关，与IT战略密切相关。IT治理发展成公司范围级流程。 优化级 对IT治理问题和解决方案有前瞻性的理解，并做好有关准备；利用先进的思想和技术进行培训和交流；通过持续改进，与其它组织的成熟度比较，业务流程已超越公司外的最佳实践；实施的这些政策已使组织，人和流程快速适应并全面满足IT治理的要求。以广泛的、集成的和得到优化的方式使用IT自动化工作流，并提供工具提高质量和效果。 IT组织架构现状评估 现状 组织架构 中国人寿信息技术系统由超过1400名的有经验的技师、技工和技术专家组成，其中拥有大学本科及以上学历的人员占75％以上，是中国寿险业界最大的最有经验的专业技术人员队伍。（数据来源：信息部统计.xls） 中国人寿IT组织架构与公司机构平行即总公司——省级分公司——地级分公司都有IT组织，部分县级支公司有IT组织； IT组织有两条报告路线。一条是向属地公司 报告，一条是向上级IT组织报告； 松散的四级管理体系，各级对所在公司总经理室负责； 不同分支公司IT组织架构差异较大； 全国有较高开发能力的人才约有100人左右，总公司有不到20人。 职责权限划分 没有统一的岗位职责、权限标准； 人员多的公司分工相对细、职责相对明，但各地差异较大。 差距分析 优势与问题 现有组织架构的优势： IT组织贴近业务一线 灵活性高 现有组织架构的问题： IT组织分散，组织之间相对孤立 总公司IT力量薄弱，对分公司的指导和统一协调速度慢； 各个省公司的IT小而全：应用开发处于救火状态； 全国IT的力量分散，造成资源浪费； 需求与期望 对IT组织架构的需求与期望： 普遍认为IT垂直化管理是趋势，但目前条件不成熟； 加强总公司IT组织； 标准化各级公司的IT组织与职能； 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 初步改进建议 Action 总公司开发力量薄弱，各省公司IT部门均有应用开发和运维管理；同时各分公司应用开发和运维人员普遍缺乏，造成有时不能对业务部门的需求进行及时响应。 IT人员缺乏 IT人员没有整合利用 IT组织架构重组 各分公司IT组织架构不统一，不利于实施垂直管理 各地IT 2条报告线路 逐步从松散型向紧密型、实行垂直化管理的组织模式靠拢 IT人力资源现状评估 现状 职业发展 几乎没有成文的职业发展计划； 针对个别骨干人员的朦胧计划； 激励机制 激励机制模糊不透明； 绩效考核 全国很不平衡，有些公司几乎没有绩效考核； 绩效考核没有量化，标准不科学； 薪酬体系 IT薪酬体系单一为行政体系 较少与绩效相关 培训体系 没有完整的IT培训体系； 大部分基层员工缺乏基本培训； 缺少培训计划或培训计划执行不力； 缺乏培训资源； 缺乏系统地学习先进的保险经验。 差距分析 优势与问题 优势： 初具规模的组织与技术队伍； 职员对公司有较高的忠诚度； 基层职员比较了解业务需求； 职员平均受教育程度高； 问题： 部分地区薪酬吸引力不够，一定程度上影响职员工作积极性； 知识结构不平衡； IT岗位和其它岗位没有明确的区分； IT人员没有一个完善的“职业计划”； IT技能培训缺乏统一的计划； 需求与期望 需求与期望的描述： 希望薪酬体系符合劳动力市场的差别； 技术与行政双轨升迁体系； 针对个人的完善的职业发展计划； 完善的教育培训体系； 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 初步改进建议 Action IT人员没有一个完善的“IT职业发展计划” 缺乏针对IT人员的职业生涯 设立技术与行政双轨升迁体系 IT技能培训缺乏统一的计划，业务培训一般化，缺乏针对先进的保险经验的学习 没有针对IT人员的培训体系 建立针对IT人员的培训体系 缺乏完善的绩效考核体制和激励机制 IT人员的绩效考核和激励方式应有别于业务部门 建立针对IT人员的绩效考核和激励方式 IT服务管理流程现状评估 现状 中国人寿的IT服务管理分为总公司、省公司、地市公司3级服务管理体系，总公司IT服务管理内容包括：对省、市公司的运营进行指导和管理；总公司主机设备、系统软件、应用系统的安全运行、维护与管理，以及总公司机关的IT运行管理。省公司IT服务管理内容包括：对市公司的运营进行指导和管理；省公司的IT运行管理。市公司IT服务管理内容包括：市公司IT运行管理。 总公司目前已完成《安全运行管理手册》、《中国人寿保险公司运行管理制度》、《计算机设备管理及维护暂行规定》、《计算机网络管理暂行规定》、《计算机信息系统安全保密管理暂行规定》、《中国人寿办公自动化系统管理规定》等相应的运行管理规定，指导各分公司的运行管理流程，克服由于地区差异带来的管理规范不一致，逐渐改变全国不统一、各分公司有自己不同的运维流程现状。 省公司目前正在逐步按照总公司的运行管理规定，按照全国统一的规范进行运维管理，各省公司均有各自的运营管理日志，但详细程度各地不同。 在进行维护管理的过程中人员的技术水平、责任心等因素对IT运行维护的效果影响较大，相应的管理工具缺乏，或有工具但没有很好的利用。 IT服务管理流程现状总结如下： IT服务管理流程 中国人寿流程现状 运维管理流程 有基本的流程，尚需完善 事件管理流程 没有完善的事件管理流程 问题管理流程 无完善的问题管理流程 配置管理流程 无 变更管理流程 部分分公司有初步的变更管理流程 服务级别管理流程 无 以下是对反馈问卷中几种运维管理的统计分析： 差距分析 优势与问题 经过调研，可以发现现有的IT服务管理流程中有以下的优势与问题。 优势： 有基本的运维流程； IT运维的重要性得到普遍认同； 问题与不足： 没有统一的完整的IT 运维模式； 现有的模式基本上是属于应急救火式的管理，IT人员的工作被动； 总公司在运维支持统一性上应发挥更大的作用； 缺陷报告响应速度慢，没有流程可以追踪； 临时任务多，下级公司往往不知道上级公司的计划； 缺乏系统管理工具 没有一个集中监控点，可以全面监控整体IT运行的状况； 用户反映问题的渠道不通畅； 需求与期望 通过对各级业务部门和各级领导的访谈，我们总结未来业务部门的需求和期望如下： 稳定的IT运行环境，尽量减少系统的不可用时间； 及时处理系统出现的故障； 迅速相应业务需求的改变； 提升系统维护能力，提高问题响应的速度； 将来要进行的数据集中，将对IT服务管理的服务质量提出更高的要求； 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 初步改进建议 Action 没有统一的完整的IT 运维模式 缺乏全国统一的完善的IT运维体系 建立统一、规范的运维管理 现有的模式基本上是属于救火队式的管理；缺陷报告响应速度慢，没有流程可以追踪 缺乏事件管理及问题管理流程 建立事件、问题管理流程 IT部门在人力、资金有限的情况下难以满足业务部门的过高期望。 业务与IT没有对合理的服务水平进行沟通 建立服务级别管理 进行软件升级、新系统上线出现不匹配的情况。 没有变更管理 建立变更管理流程 项目管理现状评估 现状 一般项目管理 项目综合管理 目前是部门间的沟通，或是个人间的沟通。没有制度方面的保证。例如：在业务推出新的产品时，缺乏与IT的沟通，IT有时无法及时更新系统满足新的产品的需求。部分省份有主动制定的一些项目开发计划，其它大都是根据业务和管理的需要临时制定的。关于项目执行计划大都缺少文字记录。整个项目的文档工作比较差。 项目范围管理 普遍做的比较差，缺乏范围界定计划书，细分子项目、范围核实和范围变化控制。 项目时间进度管理 普遍做的比较差，缺乏对活动的时间估计、进度编制和进度控制。 项目成本管理 基本没有进行项目成本管理。没有与第三方合作的管理办法，成本、质量控制方面不好 项目质量管理 基本没有进行项目质量管理，主要由需求方进行阶段性的确认和测试。 项目人力资源管理 目前开发以合作方式为主，人寿出项目经理，不利于人员技术方面的培养。激励等措施不到位。 项目沟通管理 目前是部门间的沟通，或是个人间的沟通。没有制度方面的保证。例如：在业务推出新的产品时，缺乏与IT的沟通，IT有时无法及时更新系统满足新的产品的需求。 项目风险管理 基本没有进行项目风险管理 系统开发 核心业务系统由总公司负责；它往往不能兼顾全国的需求，江苏上海和深圳维持自己的系统，维护量很大。 总公司和COPIA在北京开发的系统，远离保险业竞争激烈的地区，在面对市场的灵活性和反映的迅速性上不如本地的公司。 开发管理流程需要进一步完善和标准化，特别是文档管理、测试和版本管理方面需加强。 系统测试 总公司下发的应用软件层层测试；（加说明，详细解释说明） 软件部署 1．应用软件部署时没有与采购及业务等部门的协调 差距分析 优势与问题 经过调研，可以发现现有的项目管理现状中有以下的优势与问题。 优势： 有基本的开发计划和测试计划； 项目管理的重要性已日益得到重视； 问题与不足： 没有统一的完整的项目管理制度； 沟通没有制度方面的保证； 没有完善的制度、策略来调动IT人员的积极性； 项目的成本、质量等方面控制不好； 临时任务多，下级公司往往不知道上级公司的计划； 缺乏项目管理工具 没有围绕应用的解决方案包和上线流程 系统测试造成效率低，人员浪费 系统 需求与期望 通过对各级业务部门和各级领导的访谈，我们总结未来业务部门的需求和期望如下： 需要某种机制（制度）使双方更好的沟通，公司高层应该设法从组织上保证； 建议由高层确认，在业务部门设立IT联络人员； 需要有项目管理的人员； 领导需要制定相应制度、策略来调动IT人员的积极性； 要建立一套完善的开发流程，管理机制，开发产品的质量要高，能够采用先进的技术手段，满足需求； 中国人寿应掌握核心技术； 开发应面向市场、面向国外先进的保险经验，技术具有前瞻性； 在标准化开发管理流程同时，提高开发效率。 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 初步改进建议 Action 没有完善的项目管理 流程规范 缺乏项目管理规范 建立项目管理规范 系统开发灵活性与上市时间与业务希望有差距 缺乏系统开发管理规范 建立系统开发管理规范 软件测试与部署造成重复劳动和与其它部门不匹配 缺乏系统的软件上线流程 建立系统的软件上线流程 外部资源利用策略现状评估 现状 外部资源的合理利用是推动中国人寿信息技术的发展重要因素，中国人寿的外部资源主要包括设备供应商、软件供应商等。 外部资源与中国人寿的合作模式主要有： 产品供应商：中国人寿直接向供应商购买成熟的产品，包括硬件设备、软件产品等；（代表厂商：HP、IBM、DELL、CISCO） 服务提供商：中国人寿向服务提供商购买维护、咨询等服务；（代表厂商：HP、IBM、Mckinsey） 应用软件提供商：中国人寿提出项目需求，按照项目管理的方式进行考核。（代表厂商：Copia） 外部资源的管理方式： 跟踪每笔供货合同，按照合同约定对供应商进行管理； 建立供应商资格审查制度，只有通过审查的供应商才能为人寿供货； 征求使用单位对服务质量的意见，经过综合评定，对成绩最低的服务商第一年警告，第二年则清除； 按照项目管理的规范，通过每周的报告和定期沟通来监控项目进展； 对供应商的响应速度、技术实力、服务质量等方面进行考核。 差距分析 优势与问题 优势： 普遍认识到外部资源的重要性； 针对不同产品和服务提供商有不同的合作策略和管理方式； 对外部资源的满意度较高； 问题： 供应商单一，没有形成竞争局面； 对开发商的管理，缺乏刚性的统一的考核手段； 需求与期望 问题出现时能够快速解决； 减少系统出现的问题，降低系统升级、打补丁的次数； 提高软件开发外包的时效和能力； 初步分析 编号 ID 观察 Observation 根本原因 Root Cause 改进建议 Action 供应商单一，没有形成竞争局面 缺乏供应商管理体系 建立供应商管理体系 对开发商的管理缺乏刚性的统一的考核手段 缺乏针对开发商的项目管理体系 建立针对开发商的管理考核体系 IT投资成本效益分析 现状 IT预算与投资流程 中国人寿目前采用如下的IT预算与投资流程： 年底由分公司根据下面的需求，作一个大致的预算； 总公司进行归类，根据工作任务规划，向计财部门汇报; 由计财部向总经理室汇报; 一旦计划通过， 设备的具体型号可以修改，再由总公司统一采购分发; IT投资力度 上图为2000年中国人寿各分公司电子化资金与保费收入的比例。 原始数据来源：历年投入.xls 上图为2001年各分公司电子化资金与保费收入的比例。 上图为2002年分公司电子化资金与保费收入的比例。 由以上地统计结果可以看出IT的总体投入偏小。 IT成本的构成情况 可以看到硬件投资比例最大占%, 软件其次，比例为%，其它项目如开发、咨询、培训、工资等所占比例很小。 原始数据来源：各分公司调研问卷 效益评估 可以看到IT投资的效果是被普遍认可的。 差距分析 优势与问题 和保险同业相比，人寿的IT投资偏小；但较好支持人寿各地的业务，投资回报较好； 来源：Mckinsey IT远景目标及战略报告 集中采购是可以降低成本的，但关键是如何把握度，要注重其差异性，目前集中采购响应速度太慢; IT投资比例失调，硬件投资大，但服务、咨询等投入太少; 没有财务开支渠道和费用支持分公司软件开发，电子化资金只有硬件，没有软件开发费用。 需求与期望 加强IT投入，包括人员、系统开发、服务和硬件等方面的投入。 协调好集中采购的控制和灵活性的关系，提高效率。   初步分析 编号 ID 观察 Observation 根本原因 Root Cause 初步改进建议 Action 和保险同业相比，人寿的IT投资偏小； 缺乏IT战略对IT投资的指导 明确 IT投资战略 目前集中采购响应速度太慢 缺乏相应的规范，造成各职能部门协调时间过久。 完善IT部门的预算和采购规范 IT投资比例失调，硬件投资大，但服务、咨询等投入太少 前期基础性建设需要大量投资于硬件、软件等 观念问题 统筹规划各部分的投入应逐步加大服务、咨询、人员投入 IT治理总体评价 通过第1阶段的调研、分析评估阶段，结合IT治理成熟度模型，我们评价中国人寿目前的IT治理水平应在初始级并正在积极向可重复级过渡的水平，通过分析未来业务战略对IT的要求，以及业务和IT部门的期望，我们认为中国人寿在5年后的IT治理水平应达到已定义级，并向已管理级过渡的水平。 经验参考 IT治理评估总结 附录 资料：关于数据质量的信息成熟度模型 定义一个信息信息成熟模型（IMM）首先需要确定含有信息管理和用法的特征。在这些特征中，数据质量是最主要的（查看图1和图2）。最初考虑数据质量，我们能够建立以下部分IMM结构，这与业界认可的能力成熟模型（Capability Maturity Model）是一致的。 Level 1:意识。最低的数据质量成熟度的组织也意识到数据质量问题正影响企业决策支持。它们没有正式主动的来清理数据，并且没有能够在特定紧迫需求（例如，产生一个清理的邮件列表或一个可任意使用的、提取于定制译码的数据。）的基础上来满足需求。组织往往容易忽视这个问题，或者希望安装新的/升级的系统后立即解决该问题。信息被看作是一种应用程序的偶然副产品；并且客户、供应商和合作伙伴比企业员工自身更容易受到数据质量问题的困绕。我们发现全球3000家企业中大约有35%如今处于这个级别，到2005年将降到20%。为了获得更高的数据质量成熟度，这些组织应当努力改善内部对数据质量问题及其影响的意识和交流；并且能够在不同的数据质量问题上得到“锻炼”。 Level 2:反复。在这个层级上，决策和事务经常由于对数据质量问题的怀疑而发生疑问。应用程序开发者使用简单的编辑/控制，来标准化数据格式；并且手工或自行在一个应用程序数据库进行部门级/应用程序级操作。许多员工也已经觉察到信息用于进一步的业务流程理解和改善，但是整个企业的数据质量问题仍需上升到高层级战略决策制定上。在这种层级上，数据质量问题更容易影响维修或服务人员，它们访问正确的操作数据来有效的完成他们的工作任务。大约45%的企业如今处于这个级别，到2005年将降到25%。这些组织应当关注更好的理解和定量数据质量的企业影响，采取数据质量相关的数据管理指导方针。 Level 3: 前摄。当信息被看作是一种改善企业业绩的真实助推器，并且企业分析师感觉到数据质量的问题最尖锐时，信息成熟度便达到了中等层级。数据质量已经成为IT规则中的一部分，并且主要的数据质量问题已经文件化，而不是被分析或定量化。无论如何，数据清理通过商业数据质量软件在下游进行操作（例如，在部门级IT或在数据仓库中），数据质量软件可以在记录的基础上，清理、识别/匹配并标准化操作。这些流程改善了数据，来进行有效的战略或策略决策。数据质量导向的数据管理的指导方针已经分布，但是还没有得到实施。我们的研究表明15%的企业如今处于这个级别，到2005年将上升到35%。为了达到下一个数据质量阶梯，企业应当超越以前的数据质量问题的解决，并简单编译来持续检查和修补数据，以让其接近原始数据。另外，他们应当实施数据管理政策的格式，来在企业流程的层级上发现并解决数据质量问题。 Level 4:管理。当信息被当作IT部门的一个关键组成部分，并作为一种企业资产来讨论时，信息成熟度便达到了第二。数据质量已经成为一个首要的IT功能和主要职责，并且已经实施的商业数据质量软件已经得到在企业级的定期系统测评和准确性、完备性检查。数据质量是具体的与企业问题和流程业绩挂钩。大多数清理和标准化功能在源头得到执行（也就是说，在数据产生、捕获或接受时）；并且名字/地址数据质量在一个国际化的基础上操作。严格而灵活的数据质量流程可以吸收信息的数据来源，并且如果不是无缝时，直接修补不可预测的错误。数据质量功能被体现在主要的企业应用程序中，确保可信的进行决策制定，并且数据质量相关政策被很好的设立和监视。既有5%的企业已经达到了这种层次的成熟度，我们希望这个数字到2005年能够上升到15%。要想攀登到数据质量优秀需求的顶峰，企业需要继续制度化数据质量的实务。 Level 5: 优化。处于该层级的数据质量，会把信息当作一种企业级资产（而不仅仅是一种IT资产），对待信息更像物质资产和资产的运作方式。数据质量是一个成长中的战略性企业创新，具有可认证的ROI。许多数据质量边缘的特征（例如，流通时间、幅度、深度和准确度）继续得到测量和监控。数据可以适时用第三方供应商（也就是说，额外的人口统计或市场数据）来丰富。多级鉴定用来证明合作伙伴、职员、客户和供应商之间的关系。关键的非结构化信息（例如文件）应在数据质量的控制之下。元数据/数据被加上一个质量指示器，来与信任的或知名的信息（特别是数据仓库）问题相关联。数据质量对于可信的适时企业流程自动化是足够的。并且数据质量相关数据管理也被自动化。只有不到1%的企业已经达到了这个层级，但是到2005年可以达到5%。维护卓越的数据质量在这个层级上是很难的。无所不在的成本削减压力、新的应用程序创新、政治结盟，以及兼并和购并都将消耗数据质量资源和解决方案。组织不必依靠一个独立的领导，但是一个优秀的领导可以来确保数据质量融入文化、培训、IT结构/基础设施、金融模式和业务流程。 资料：Informix向Oracle或DB2的移植 Oracle: Oracle Migration Workbench（移植工作台）是可以使从第三方数据库系统向 Oracle 平台（Oracle8i 和 Oracle9i）的移植过程得以简化的工具。它在集成环境中移植整个数据库模式（包括触发器和存储过程）。 可以免费下载 Oracle Migration Workbench 发行版 。 Migration Workbench 核心特性 将一定范围内的第三方数据库移植到 Oracle9i 平台。 在可以进行更改的信息库中存储有关产品数据库结构的信息。 通过联机捕获或脱机捕获检索源数据库信息。 解析存储程序、触发器和视图，并将其转换为 Oracle PL/SQL 和 Pro*C。 提供了高级自定义功能，如更改数据类型映射以及删除并重新命名对象。 生成有关移植状态的报表。 生成创建目标 Oracle 数据库的 DDL 脚本。 为数据移动生成 SQL Loader 脚本。 使您能够在目标 Oracle 数据库中选择可以移入对象的现有表空间。 在 “Progress” 窗口中显示有关移植的信息、错误和警告消息。 自动解决对象名冲突，例如与 Oracle 保留字的冲突。 版本支持：Informix Dynamic Server （产品版）和 （测试版） 支持的转换特性 特性支持 Informix 表 Y 视图 Y 索引 Y 组/角色 Y 用户 Y 约束 Y 权限 Y 用户定义类型 N/A 存储过程 Y 触发器 Y 嵌入式 SQL ESQL/C 移植到 Pro*C 其他特性 N/A IBM: 我们的计划是整合Informix、DB2以及其他信息产品的发展战略，这项工作将分步骤进行，每一个DB2的发布版本将包含一些附加的Informix能力，应用移植将取决于这些Informix独有的特性于何时被包含到DB2中。 IBM正在努力将Informix的技术优点融入到DB2产品线中，也就是说：IBM推荐现有的Informix用户及合作伙伴考虑用DB2实现新的应用。 －摘自IBM关于Informix和DB2产品未来发展策略的白皮书 独立第三方报告资料： 独立研究机构Morgan Stanley公布的调查报告显示：51%的CIO们把Oracle作为首选的数据库供应商，而IBM和Informix加在一起的数字还不足22%，Morgan Stanley认为，在最了解当今数据库性能的CIO群体中，Oracle数据库继续雄居领先的地位。AMR Research在2001年11月提供的一项研究报告同样表明，在所有计划改变其原有数据库的Informix用户中，有50%将转向Oracle。Evans Data研究报告也证实，Oracle是应用开发者首选数据库，Evans Data在研究报告中指出，大多数开发者在选择数据库时主要考虑可靠性、可伸缩性、完整性以及总拥有成本等因素，在这些方面，Oracle都获得了开发者的认同。 资料 项目管理简介 惠普公司项目管理实践遵循项目管理协会（Project Management Institute）的基 本原则，结合一套面向客户，结构化的项目管理方法论－FocusPM（专注项目管理）。这套方法论特别适用于信息技术（IT）项目管理，惠普公司在全球范围内已广泛地运用于金融、政府、制造业、电信等用户的IT项目管理中。 FocusPM作用于整个项目生命周期，并将这一周期划分为六个阶段，初始阶段、计划阶段，选择阶段、实施阶段、保证阶段和支持阶段。每个阶段由一系列活动组成，而每个活动是通过一个或几个任务来完成。每个任务的执行都规定了条件和操作流程，该项任务完成后，产生规范的结果。FocusPM过程结构图如下： 图： FocusPM项目管理方法 说明： 1.初始阶段：记录和核实客户需求以保证准确的解决问题 2.计划阶段：根据客户需求，设计方案，并制定详细的项目计划 3.选择阶段：与用户核对方案设计和项目计划，商谈必要的协议，使惠普公司与客户对该项目达成一致。 4.实施阶段：惠普公司的项目经理执行项目计划和管理项目资源，保证项目按时在预算内完成，并取得用户的满意。 5.保证阶段：将系统的操作、管理和有关知识逐步转移给客户，监督系统性能如预期指标 6.支持阶段：如果与客户达成支持协议，执行支持计划。 FocusPM为项目经理提供易于理解和验证的原理、简单实用的工具和规范化的流程。使用FocusPM管理项目，使项目经理、惠普公司和用户都能受益，这主要体现在： 1.明确定义项目经理的角色和责任。 2.在全球范围内规范项目管理的方法，建立可操作的流程。 3.分享优秀的经验，建立可重复使用的经典案例。 4.使复杂、庞大项目的管理简化和清晰。 5.减少项目失败的风险。 6.降低项目成本。 7.项目队伍的工作得到认可，最终用户满意。 ＨＰ项目管理运作基于下面原则： 将项目计划与其它业务计划结合 项目完成以满足客户需求为目标 明确定义项目的可交付物、里程碑和预期目标。 直接掌握项目要素和实施过程。 持久地与最终客户分享。 通过早期的计划分析和对例外的准备降低项目风险。 有效的控制项目变更和费用 有效的和灵活的项目沟通。 资料 IT服务管理（ITSM）简介 HP的ITSM参考模型具体化了IT基础架构库（IT Infrastructure Library ，简称ITIL）的最佳实践。ITIL最初是由英国政府为提高其客户服务质量而建立，并在整个欧洲被采纳和实现，同时美洲也正在推广当中。HP的ITSM顾问经过大量的不同的企业的应用实践，将其溶入到ITSM参考模型当中，并相应地增加了实践经验，使其更加具有可操作性。 在与世界范围的IT组织的交往中，惠普深刻地认识到确定下列事项是非常困难的。 需要的IT流程 服务管理的组织要求 流程导致的技术 与重要的需求及可能的解决方案在企业范围内的沟通相关的问题 惠普投入了大量的时间及精力帮助顾客解决这些问题，并且成立了由IT服务管理专家组成的工作组，其目的就是开发一个模式，以供企业IT组织参考。 实践证明，这个模式作为一个高级的、充分整合的IT流程关系图，对于世界中的公司理解其问题及找寻解决方案具有不可限量的价值。另外，做为一种参考工具，这个模式提供了一个IT流程的一致性的表示方法及共通语言，这对于所有对于IT流程要求及其解决方案感兴趣的组织都是十分有益的。 惠普IT服务管理参考模式包括了许多IT基础结构库（ITIL：IT Infrastructure Lib）中的最佳实践。ITIL最初是由英国政府开发的，目的在于对其向其IT顾客提供的IT服务进行更好的管理。ITIL由一系列的书构成，并被大多数的欧洲国家所采纳及实施。而现在ITIL正在逐渐被美国的公司所采纳。惠普ITSM参考模式开发小组采纳了ITIL中的可应用于企业领域的最佳实践惯例，并将它们溶入模式中，同时加入了世界各地的惠普咨询顾问的经验。这些经验是他们在惠普公司内部或与惠普的顾客共同开发及实施服务管理解决方案时所得到的。 其结果是产生一个包容了ITIL及行业经验中的最佳实践内容的模式。同时开发小组使得模式可以反映“如经营公司一样地经营IT，而不仅仅把它当作公司内部的部门”这一新的概念。这使得ITSM参考模式中具有一些ITIL中所不具有的流程。 但是在整个模式中还是采用了许多ITIL的术语及定义，虽然有一些是被加以修改，以反映惠普的经验及观点。这种做法是通过有意识性地采用全球共通术语、定义及概念，以使公司能够更容易理解这个模式。 需要注意的是，惠普ITSM参考模式可以应用于任何企业的IT部门，无论是外包的或自营的，无论其规模大小、分布如何，还是是否支持电子商务。虽然这个模式是以分布式的企业环境为主要对象，但是它还是可以适用于传统的数据中心结构，原因在于它对于非整合事件的描述现在普遍存在于主机中心的流程模式中。 惠普也在其公司内部使用这个模式，并将其作为一种增进部门间沟通、生产及服务开发的工具。 惠普IT服务管理参考模式 Service Delivery 图表 1 ITSM 参考模式流程组 服务交付保证 基于几个原因，这个流程组被置于ITSM参考模式的中心。而其他四个流程组也被有意识地置于中心的四周（参照图5中的箭头）。第一，这个流程组中的流程可以提供模式中的其他所有流程所需的IT环境的稳定性。如果没有服务交付保证中的流程，则模式中的所有其他IT流程将都不能够有效运行。如果“救火”成为众人活动的焦点时，其他的流程当然无法进行了。而这就是在缺乏这个流程组的流程时的必然结果。第二，服务交付保证流程可以与模式中的所有其他流程进行“接触”，而这种接触通常会不止一次。基于这些原因，将这个流程组置于模式图的中心位置应该说是合理的做法。 业务 - IT 调整 这个组中的流程主要着眼于将IT作为“内部公司”来运行的概念。这些流程的活动可以决定服务市场潜力、寻找并达成IT与其顾客在公司要求及IT能力之间的共识。最后，可以形成IT策略以便使IT附加价值达到最大化。因此可以说这些流程具有策略性的性质。 服务设计及管理 这个组中的流程可以使IT将IT策略（即作为业务-IT调整过程表现结果的“理念”）转化成为有计划的服务（即“现实”）。其活动包括服务水平的定义；建立、交涉及签署服务水平协议以及基础结构及数据安全性等。服务可提供性、服务能力及IT服务成本信息连同其他模式中的其他流程都通过本组中的流程间的相互作用整合到服务合同中。 服务开发及配置 本组中的过程可以使IT对于现有的服务进行更新并且开发新的服务及相关的基础结构组件（如程序、工具、硬件、软件安装、应用程序开发、培训计划等）。一旦服务及其组件已经得到成功的测试，它们将会被配置并整合到生产环境，然后在最终项目结束及产品发布之前还需要对其进行一系列的测试。 运营桥梁 本组中的运营流程通过协同工作来提供IT环境所需的指令、控制及支持。这些流程同时也可以管理顾客满意度。着眼于服务交付，这些流程可以促成IT环境中的运行、监视及维护。 经验表明，服务的周期是动态的，因此要比用平面图形表示的要复杂得多。这意味着在这个周期的不同时点被执行的流程可能具有重复性，并且包含有与其他多数的IT流程的相互作用，需要有不同的反馈回路来保证质量。尽管如此，在服务在顾客眼中还只是隐约的幻想到服务真正得到交付的这段时间内，ITSM参考模式的结构仍然可以在服务周期内向一般活动提供高水平的指导。 下面对于模式中的每个流程的简单描述表明了模式的一般工作流程以及一些主要流程的交付及质量控制。 下图是HP ITSM的模型中的内容简介。 图：惠普IT服务管理参考模式 FocusPM( Page PAGE \* MERGEFORMAT 2 of NUMPAGES \* MERGEFORMAT 204 DOCPROPERTY "Tool_ID" \* MERGEFORMAT Template ( DOCPROPERTY "Version" \* MERGEFORMAT 6 / DOCPROPERTY "Release_Date" \* MERGEFORMAT 30-Apr-2001 ) DOCPROPERTY "Project_Document_Id" \* MERGEFORMAT Project Document Id FILENAME \* MERGEFORMAT IT Assessment report - - Last printed PRINTDATE \@ "d-MMM-yy" 14-Nov-03 PRINTDATE \@ "HH:mm" \* MERGEFORMAT 15:38 Chart1 6 16 10 0 应用系统集中期望调查 Sheet1 全国集中，应用部署在总公司 6 全国业务数据实时集中，应用部署在省公司 16 省数据集中，应用部署在省公司 10 地市集中，应用部署在地市公司 0 Sheet1 0 0 0 0 应用系统集中期望调查 Sheet2 Sheet3 我们建议中国人寿采取阶段性的 IT 实施方案 资料来源：麦肯锡分析 前台 流程再造 启动 IT 转型 2004 年 6 月 2005 年 6 月 流程再造 建立核心系统 在一个省级公司实施/试点 在全国推广实施 将业务迁移至新系统 利用世界一流的 IT 技术，以获取竞争优势 逐步淘汰遗留系统 试点流程，进行 IT 原型设计 核心运营 系统再造 试点流程，进行 IT 原型设计 设计新产品业务要求 和技术要求 评估现有 架构的 生命力 集中管控 IT 决策 确定用户信息需求 加速省级数据中心整合 在全国推广实施 基本风险管理系统 建立新的 IT 管控和管理流程，和新的 IT 组织 将 IT 报告正式列入总部管理日程 高效管理 实施统计分析系统 建立中央数据仓库和先进报告能力 在全国推广实施高级风险管理系统 成立第一家 全国数据中心 整合进第一家 全国数据中心 业务流程再造/ 渠道管理系统 1 业务流程再造/ 核心运营系统 2 新产品/服务支持系统 3 技术重构 4 为资产管理公司 设计业务和系统要求 为资产管理公司推广实施系统 IT 组织和管控 5 风险管理系统 6 管理信息系统和共用数据仓库 7 数据中心整合 8 确定新系统参数 在全国推广实施核心运营系统 设计未来 IT 架构和 数据库 管理系统 确定新架构和 数据库管理 系统的原型 定义应用 系统功能 定义应用 系统功能 在全国推广实施技术架构 在全国推广实施基本前台流程和系统 在全国推广实施高级前台流程和系统 设计业务要求 和技术要求 成立第二家 全国数据中心 整合进第二家 全国数据中心 推广实施 新系统 图表1 针对目前系统管理的满意度调查 Sheet1 基本满意 不满意 Sheet1 0 0 针对目前系统管理的满意度调查 Sheet2 Sheet3 BW:256K~2M PSTN Site 1 IP WAN (Primary Voice Path) Gatekeeper(s) A VSM V V ICM CC PG IP IVR CM Site 2 A VSM IP IVR CM Site 35 A VSM PG IP IVR CM V PSTN Romote Nodes: 3-10 V Romote agents 2~4 PSTN PSTN PSTN Romote Nodes: 3~10 V Romote agents 2~4 IP WAN Total 35 sites Side A Side B IP WAN ICM Link IP WAN Link TDM Voice Link IP LAN Link Agents Agents Agents 1~2*E1 1~2*E1 1~2*E1 BW:256K~2M BW:512K~1M BW:512K~1M BW:512K~1M Applicaton Server Applicaton Server Applicaton Server PG 图表2 是否有实施新的管理系统的计划且能否满足需要？ Sheet1 基本满意 不满意 84% 12% 4% 没有 有，但不能满足 有，且能满足 Sheet1 0 0 0 是否有实施新的管理系统的计划且能否满足需要？ Sheet2 Sheet3 图表3 是否有合适的系统管理流程支持新的管理系统？ Sheet1 基本满意 不满意 84% 12% 4% 没有 有，但不能满足 有，且能满足 % % 没有 有 Sheet1 0 0 是否有合适的系统管理流程支持新的管理系统？ Sheet2 Sheet3 调研分析－三省中国人寿业务管理状况 1：9 1：10 1：31 员工/ 代理人 业务管理部门独立架构； 使用自身开发业务系统； 自身组织电子商务开发 经济发达特区 3，563 320 深圳 业务集中的业务管理与操作流程 需要总公司提出； 物流费用不了解 经济发达省 34个外资 2，900 3，000 广东 集中后含物流、集中单证出单、 纸张、数据录入成本总计3元/单； 集中前成本为6元/单； 物流费用全区全年120万 老少边穷地区 “西部+2” 16，000 500 广西 主要业务特征 区域特征 代理人数 员工数 分公司 图表2 1 23 22 8 1 Chart1 核心交换机品牌分布 Sheet1 27 6 2 其他品牌 % Cisco % 4 31 Sheet1 0 0 核心交换机品牌分布 Sheet2 Sheet3 Chart2 核心路由器品牌分布图 Sheet1 27 6 2 其他品牌 % Cisco % 4 31 其他品牌 Cisco Sheet1 0 0 核心交换机品牌分布 Sheet2 0 0 核心交换机品牌分布图 Sheet3 Chart4 5 2 3 16 应用间数据交换调查 图表3 0 8 17 4 0 Chart3 0 6 22 3 Chart2 2 20 30 8 Sheet1 应用系统总体能够支持未来业务要求 能够满足业务需要,只需要升级 2 基本能满足业务需要,但需要做调整和改变 20 满足未来业务需求，需要做较大的调整和改变 30 不能满足业务需求，需要做较大的调整和改变 8 Sheet1 0 0 0 0 Sheet2 应用系统总体能够支持未来业务要求 能够满足业务需要,只需要升级 0 基本能满足业务需要,但需要做调整和改变 6 满足未来业务需求，需要做较大的调整和改变 22 不能满足业务需求，需要做较大的调整和改变 3 Sheet2 0 0 0 0 Sheet3 未来实施计划 – 业务战略 六项业务战略 个险代理 大众富裕客户 银行保险/新渠道 团险 健康/意外险 资产管理 达到世界领先水平 3 – 5 年 加强核心能力 12-18 个月 扩展领导地位 12-36 个月 实施组织结构转型 推广销售业绩改善举措 建立新渠道业务部门 扩大网点覆盖 提高运营效率 实施组织结构转型 建立关键客户管理式的销售方式 建立新的业务部门 建立核心技能并降低理赔率 探索管理式医疗模式 锁定意外险销售渠道 建立独立新公司 建立针对新投资渠道的技能 通过销售队伍分级管理进一步加强队伍专业化 改进价值链的主要环节 设计业务模型并与潜在合作伙伴开始谈判 通过建立排他性合作伙伴关系改变行业结构 通过发展产品捆绑、现场销售和卓越的投资管理技能提高团险竞争力 [建立独立的健康险保险公司] 发展意外险新渠道 建立合资公司，开始试点 建立第三方资产管理业务 뗒뗏돍 귔쨊઼ꖵ혊뒤삦í 쫕츊૱ꚴ쀊í 욲츊૱횷츊૶ 쫗者뗏돍 ꢸ𥳐쮺 留듀뗏돍 뗏돍쏖 ꒹쫗뗏돍 ꦶꖵ뗏돍 뛍쫗뗏돍 쿉즽쫗 ꎱꞻ ꛓ헊ꎱ톷 调研分析 – 三省中国人寿保险市场状况 保费/GDP (%) 44% 亿 2, 深圳 30% 60% 100 11, 广东 35％ 78％ 2,455 广西 保费增长率 2002年市场份额 （％） 2002年保费 （亿元） 2002年GDP （亿元） 分公司 펽� 귔쨊઼ꖵ혊¤ 귔쨊઼뻆혊¤ �뜊૖픊૊츨볥뮶쫲벮⦶ 귔볊뻆ꓖ볂 뗒 ꣍쏓 톷쏓 ꢸ𥳐쫕 쿉� 펽헊 韛즳잼쫕뻆ꓖ 잼쯕뻆ꓖ볂 FocusPM Methodology Overview Prepare Technical Solution Develop Project Scope Statement and WBS Develop Project Schedule Establish Project Resource Requirements Develop Project Risk Management Plan Develop Additional Preliminary Project Plans Develop Project Budget Resolve Inconsistencies in Project Plan Perform Project Plan Quality Review Prepare and Present Client Proposal Perform Planning and Proposal Quality Review Activities Reach Agreement on Proposal Produce Final Proposal and Project Baseline Complete Contract Perform Selection Quality Review Activities Start Up Project Conduct Project Control Project Plan Execution Schedule Tracking and Control Financial Tracking and Control Human Resources Mgt. Communications Mgt. Quality Control Risk Management Change Control Configuration Mgt. Contract and Procurement Mgt. Implement Solution Manage to the Project Plan Project Teams Client Expectations Project Deliverables Perform Client Acceptance Transfer to Warranty and Support Close Project Implementation Perform Implementation Quality Review Activities Fulfil Warranty Commitments Perform Warranty Quality Review Activities Initiate Post-Warranty Support Services Perform Support Quality Review Activities Appoint Project Manager Estimate Bid Effort of Engagement Perform Quality Review of Engagement Request Authorisation to Bid Activities PHASE INITIATION PLANNING AND PROPOSAL SELECTION IMPLEMENTATION WARRANTY SUPPORT 与顾客的相互作用 理解公司与顾客的要求 制订IT策略以达到IT附加价值的最大化 顾客满意度的管理 提供服务 监视及维护服务基础结构 解决事故及发布信息 主动性的防止问题的产生 将IT策略转化成为有计划的IT服务 制订详尽的服务设计标准 通过SLAs在成本限制内定义并管理服务水准 对于基础结构及数据提供安全保护 服务的开发与测试 根据服务设计配置服务 业务-IT调整 运营桥梁 服务设计与管理 服务开发与配置 文件化并跟踪服务基础结构信息 文件化基础结构的属性及关系 评价及控制变化 服务交付保证 hp IT 服务管理参考模型 Service Delivery Assurance 企业IT服务的开发&布署 企业IT服务规划&管理 企业IT日常运作 制定IT战略 IT的价值是什么 客户管理 如何使IT成为 值得信赖的 业务顾问 IT服务发展计划 目前和未来的那些IT服务可 更好地实现企业价值 可用性管理 如何最大限度地 实现IT服务高可用性 服务级别管理 如何定义和衡量服务是否令 用户满意 成本管理 IT总体成本预算 变化管理 如何使变更平稳运行 实施 & 测试 IT新增服务的开发 及试运行 投入运行 IT新增服务的 推广和启动 突发事件管理 如何快速响应客户 服务请求及故障定位 问题管理 如何解决故障根源及 排除隐患 运营管理 如何管理IT日常运营 配置管理 如何管理企业IT资产 配置及关联信息 IT规模管理 如何使IT规模适应 客户需求的不断变化 业务与 IT 战略整合 业务评估 以市场角度评估IT为企业核心业务带来哪些商机