企业如何布局和提升大数据能力
大数据作为现在最流行的一个方向，被很多的企业重视。那么如何提升企业的大数据能力，以发掘出它最大的价值呢？您可以从本文中找到答案。
一个成年人平均每天做出70个有意识的决定，一年就要做出超过25000个决定。企业的大部分决定是不重要的，但这其中会有一些决定给企业带来重大的机遇或者严重的后果。企业无法避免做出坏的决定，但是可以通过提升数据和分析能力降低做出坏决定的概率。
数据和分析并不是一个新的概念，早在上个世纪的两股宏观经济潮流中就已经形成。第一股潮流是劳动力从劳动力密集型产业向技术密集型产业转移。第二股潮流是二十世纪60年代企业引入了决策支持系统。随着不断增加的智力工作者从事于高科技工作，存储的资料和数据量也随之提升，数据分析在企业决策制定和执行中扮演着越来越重要的角色。
但是，企业在初期是很难整合数据并将数据分析应用于他们的日常运营中的。他们所收集的数据变量有限，且数据以不同的格式和结构存储在不同的地方。而且，从这些含有噪音的数据中过滤出相关的、重要的、有效的数据的困难程度随着数据量的增大呈指数级数上升。根据IDC的研究，从2005年到2012年，全球的数据量翻了27番，约达到2.5ZB。其中仅有25%的数据是有用的，仅有3%的数据贴有标签能被使用，仅有0.5%的数据被用于分析。
许多具有行业领导地位的企业已经意识到需要提升组织内部收集、存储、获取和分析这些超大量、极复杂的数据集的必要性。而且，企业需要为提升大数据能力投入更多的资源，以让其全面发挥潜在的作用。对大数据能力的投资需要遵循数据分析的价值链，布局于5个方面。
收集与前期准备：要有效地收集和管理大规模、复杂的数据集。企业数据产生于各自独立的数据库。为了后期能最大化数据的使用，企业应制定相应的数据标准，确保数据的准确性、一致性和可转换性。
处理：数据必须能被实时处理。在一些竞争激烈的领域，对企业来说，比竞争对手提前几天可能就能存活下来。因此企业需要评估基础架构、算法，编程语言，以提高数据的处理速度。
可视化：处理完的数据需要以简单易懂的方式呈现出来。人脑对大规模数据或文本数据的处理是缓慢的，因此企业可使用可视化工具提升对数据认知、洞察的能力。
解读数据：可视化数据应被正确地解读。企业应尽量避免错误的数据解读对认知造成的偏差。仅靠直觉亦或是极端推崇数据结论都可能将企业引向歧途。
改进：智力工作者必须提供反馈与指导。企业要促进利益相关者的反馈机制，形成反馈闭环。这种反馈机制能够对连续的分析、学习、问题识别给予支持，从而扩大信息的数量与范围。
企业要获得大数据的潜在价值的困难是艰巨的。这些困难横跨多个领域，如预算、技术的可获得性、已有基础架构的使用、运作模式等等。然而，能够有效使用数据、洞悉先机的企业将在行业里占有优势地位。而从长远来看，这样的企业将变成这个行业的领导者而非仅仅是参与者。
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: '5865575',
container: s,
size: '300,250',
display: 'inlay-fix'您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
组织级IT研发能力的构建研究.doc 9页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
你可能关注的文档：
··········
组织级IT研发能力的构建研究
　　伴随着信息技术的快速发展，信息技术研发面对的内外部环境都发生了巨大的变化，研发是获取和维持核心竞争力的重要途径，也是组织生存和持续发展的基础，而对研发结果起着决定性作用的组织级研发能力，能否及时适应变化显得尤为重要，因此，建立强大的组织级研发能力，是当前信息技术研发管理人员孜孜以求的一个重要课题。本文整合构成组织级研发能力的重要要素，以求建立普遍适用的组织级研发能力模型，本文除考虑传统的流程管理能力外，还将研发战略能力、技术能力、人员能力、支持工具能力纳入组织级研发能力的考虑范围，从而形成一体的组织级研发能力框架。
　　【关键词】组织级研发能力 研发管理 IT研发 技术管理 研发管理工具
　　近年来，由于经济社会环境日新月异、客户需求不断变化、技术环境快速更新换代、从业人员素养重心变化、管理理论和实践升级等因素，小作坊式的信息技术研发管理难以实现内外部需求间的平衡，IT研发想要取得成功和持续成功，就必须以市场和客户需求为导向建立独特的竞争优势。
　　IT研发管理不同于IT项目管理，IT项目管理主要是要保证项目在一定进度、范围、质量、成本约束下的既定目标达成，而IT研发管理则追求每个项目都有较高的成功概率，而要达到这个目的，IT研发管理的重心在于构建一种不局限于单个项目单项活动的能力，通过该能力在每个项目上每项活动上的运用，优化活动的效率、质量、成本，进而提高研发项目和研发活动的成功概率。因此，构建研发能力是IT研发管理的重要使命，为与项目管理能力作区别，本文称这种能力为组织级研发能力。
　　组织级研发能力是全面衡量整个研发组织满足市场和客户的程度的一个综合标准，可以通过对外部需求和内部资源的有效管理来获得，拥有优于业界平均水平的组织级研发管理能力，企业能够获得更高的IT研发投入产出比，进而取得业务上和商业上的成功。
　　1 IT研发管理现状及问题
　　信息技术从西方发达国家传入我国，由于文化和经济发展原因，在该领域我国一直处于学习跟进的状态，而IT又属于更新速度较快、创新性较强的领域，使得我国大部分企业在IT研发技术及管理方面的水平显著落后国外同行。我国IT研发管理现状调查中普遍存在以下几大问题：
　　1.1 研发与市场脱节
　　在企业中，市场部门的主要职责是收集市场需求、规划产品开发路标，而销售部门的主要职责是通过和客户接触，把产品卖出去。这两个部门都会通过和客户接触，收集到客户的需求，但遗憾的是，由于部门之间壁垒墙较厚，部门之间沟通困难，特别是产品开发过程中市场部门与研发部门配合脱节，市场人员所了解的客户需求未能向研发部门平滑转移，或者移交到开发人员的需求由于不系统、不详细等原因得不到重视，而研发部门又常常觉得“技术为王”，自己决定研发策略、闭门臆造客户需求来形成产品概念，以至于开发出来的产品不能真正满足客户需求，从而导致产品市场表现不成功。
　　1.2 管理方法单一和孤立
　　传统的IT研发管理，主要以CMMI、ISO9000、IPD及PMP模型为中心，试图通过建立工作流程方面的可复制性来将既往的成功经验应用到其他研发工作中去，而实际上，工作流程的可行性仅仅是工作取得预期效果的必要必要条件之一，不同的研发项目有着不同的客户、业务模式、业务需求、技术条件和技术约束、实施人员、实施环境等内外部因素和环境，仅仅通过流程约束难以达到成功可复制性的目标。
　　IT作为新生事物和专业领域，不易被其他人理解，而IT技术出身的管理人员一方面对IT管理有了先入为主的观念，另一方面工作上相对独立，缺少机会和动力去了解现代企业管理体系，以至于IT研发管理与企业管理的其他领域，如战略管理、人力资源管理、财务管理等接触点较少、协作程度较浅，这些因素导致了IT研发管理与企业管理的其他领域脱节，形成管理孤岛。
　　1.3 重复性技术劳动现象严重
　　“不要重复造轮子”可能是每个IT从业者入行被告知的第一条准则，但是实际情况往往是：找不到轮子；好不容易找到一个轮子，缺乏相应说明以致用不了；好不容易能运行，很多地方与需求不一致，不得不改；一来二去，最后还是变成自己写轮子；最为现实的问题在于大多数IT研发组织规模较小，没有能力或者意识建立统一的研发技术规划，使得经常在新产品新项目中将已经在旧产品旧项目中做过的某部分技术工作重新做一遍，造成了极大的浪费。
　　1.4 组织和人力配置与研发需求不一致
　　IT研发角色间的职责不像其它工作一样可以很清晰的划分和定义，岗位、角色、职责经常发生变动，很容易出现人员能力和实际工作要求不完全匹配的现象，在业务主导的组织里这种现象会更严重。
　　2 IT研发能力的衡量指标
　　想要建立高水平的研发能力，首先需要确定研发能力的衡量指标。IT研
正在加载中，请稍后...敏捷开发 “传奇”还是“神话”
　　文/赵志宏
　　应客观辨识披上“IT互联网”外衣的“敏捷神话”，小心踩上“神似”敏捷的“香蕉皮”。只有这样，才能创建高度互联世界靠口碑传播的“杀手级”应用和超级客户体验“传奇”。
　　“客户、产品、渠道、服务这些属于传统金融概念，生态金融的关键词是场景、媒介和体验……未来我们不一定真的需要传统金融服务，但未来我们一定在生态金融的海洋中翱翔。”有观点如此认为。
　　然而，所谓生态金融的 “场景、媒介和体验”是否可以抛开所谓传统金融的“客户、渠道、产品、服务”？“敏捷开发”是否如此神奇？“互联网IT”带来的是颠覆还是融合？“双模IT”是否可以使传统企业跟上“互联网IT”的步伐？
　　“敏捷开发”能否解决传统行业适应互联网IT开发敏捷性问题
　　Gartner公司在2015年十大战略技术趋势特别提到的“互联网IT”，在未来三年内可能颠覆企业现有业务模式、末端用户的使用习惯和企业IT基础设施。同时指出，以移动互联网、搜索智能、社交网络和多渠道为核心技术、以客户体验为主导、以全球虚拟化市场为平台的跨界创新数字电商模式(digital commerce)正进一步驱动全球消费化趋势快速发展。
　　数字电商模式对传统企业的营销理念、组织文化和决策策略产生颠覆性挑战,而数字电商的核心架构便是“互联网IT”(Web-Scale IT)。“互联网IT”是互联网公司把互联网思维、技术架构和云服务输送到企业，使传统企业的IT基础、敏捷性和技术能力得到远程重塑，形成 “互联网规模IT”或“互联网IT”。 “互联网IT”也可称为“企业互联网化”，Gartner预测，到2017年，它将成为架构方法的一种，全球50％的企业将使用这种模式。
　　“互联网IT”旨在建设可扩展（包括内外部可扩展）、低成本、稳定高效的技术架构，其特征包括：
　　◎◦拥有成千上万台机器的计算能力；
　　◎ 只需少数工程师就可以运维大量机器；
　　◎ 应用可以承载非常高的用户访问量；
　　◎ 即使有些机器出现故障，应用仍然工作正常；
　　◎◦应用每天可以升级部署应用好几次；
　　◎◦刚刚够用的流程和扁平化管理；
　　◎◦快速向用户交付产品；
　　◎◦支持开源代码及软件；
　　◎◦密切合作、高效沟通的组织架构。
　　“互联网IT”是一种在企业内部IT设施上运行的环球级别计算模式，像Facebook这样的Web-Scale实例，从来就没有“完成”的时候，而是以“敏捷开发”的方式一直处在过程之中。“敏捷开发”意味着更多的迭代，更早、更频繁地发布产品更新。它的出现不仅促使开发人员更加快速接近客户需求，让开发者开始更多关注如何加快开发周期，写出更容易实现的代码、更好的用户体验。
　　“敏捷开发方法”与“项目开发方法”的区别在于，项目有独立的产品服务开发目标和开发时间起点终点，而“敏捷开发方法”是在一个既定的短时间内将本应由一个项目组开发的独立产品服务开发任务切分成若干个有关系或没关系的开发任务，并行或迭代开发。成功的敏捷开发非常依赖高水平的CTO协调，不过，由于单个项目组可能缺乏对项目目标的整体判断、理解不清迭代间的依赖或调用关系，缺乏企业级流程、产品和数据标准的竖井式系统，后续整合竖井衍生的IT开发成本并不亚于非敏捷开发。
　　“双模IT”能否提升传统行业敏捷性IT开发的质量效率
　　传统企业渴望拥有和互联网公司一样的IT能力进行业务创新，同时提高IT运营效率、降低费用。Gartner公司指出，企业如想井然有序地实现数字化敏捷性，可同步推行“双模IT” （Bimodal IT)，即目标为可靠性的模式1和目标为敏捷性的模式2并行。
　　Gartner公司指出，企业IT部门可借此采用两种不同的方式来满足企业需求――一个专注于敏捷性和灵活性，另一个以效率、可预测性和循序渐进法为中心。“迭代式增量开发”（IID）有两种形式。最初的IID方法可被视为压缩的瀑布，通常历时8周。这种“高规格IID”适用于模式1――例如，原来的统一软件开发过程（RUP）。第二种IID形式――“IID精简版”或“低规格IID”――涉及更多同时完成的工作，降低的文件需求和较少的流程形式。它更适合模式2――例如，针对敏捷软件开发的OpenUP和微软解决方案框架（MSF）。
　　模式1和模式2大体上分别对应“传统IT”（Traditional IT ）和“互联网IT”（Web-scale IT），实行这种“双模IT”对于传统企业在高度互联世界注入敏捷基因，在保持业务稳健性的同时提高数字化悟性，确实是一种可选方案。
　　盲目采用缺乏企业级业务架构管控和组件化、标准化支撑的敏捷开发后果，可能做不到提前释放风险，导致风险遗传到上线，就像吃完低质量迭代出的“香蕉”后马上踩上自创的副产品“香蕉皮”（Banana skins，在风险管理领域常以此形容过程失控的操作风险陷阱），产生难以承受的企业声誉损失和后续更昂贵的IT整合成本。好在Gartner公司给出了配套的防患药方，随着双模IT走向成熟，其成功将从依赖IT转型驱动转化为依赖业务转型驱动，从战术性走到战略性，这个阶段被称为“企业双模”。
　　实现双模IT意味着企业拥有与之相匹配的能力和行为方式，“双模IT”能成为更好的连续统一体，这两种模式才可在企业级业务基因组图谱这同一个旋律下共舞 。
　　“DevOps”能否提升传统企业敏捷性IT开发中的协作效率
　　“互联网IT”能够实现持续部署和交付，不单是靠自动化工具，更重要的是依靠流程、组织、文化上面的变革。很多时候，思维方式、文化方面的改变比技术上更重要。同时它也开始影响运维人员更加以客户为中心，这也是出现高效协作配合（DevOps，英文Development和Operations的组合）的主要原因。开发与运营之间DevOps是实现“互联网IT”配套能力之一：
　　◎◦DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障部门之间的沟通、协作与整合。
　　◎◦DevOps的核心观点，鉴于开发人员与运维人员的关注点可能处于对立状态（即开发人员更加关注新技术、新体验，而运维人员更加关注安全、稳定），DevOps鼓励开发部门和运维部门在各自领域工作中尽早通力合作。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。它更多体现了一种思考方式以及企业文化的建设。
　　◎◦DevOps保障了敏捷高效：与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）减少变更范围与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。
　　◎◦新的应用程序和架构方法可以将企业引向营运设计之路。IT部门要从一开始就重视如何提高性能和弹性，继而开始重新思考他们的业务支持。将新的软件架构与DevOps风格结合可望成为催化剂，以提高IT部门适应变化的能力。据Gartner公司预测，全球企业CIO的25％至2020年将参与过企业网络规模IT计划，而在2013年只有不到5%的CIO是这样。
　　相当多的“传统企业”和“互联网企业”所使用的敏捷开发方法和DevOps成熟度仍然处于初级阶段。无论是一个大型转型企业项目群内各个项目组的横向协同，还是某一项目的后续纵向修改，由于缺乏“企业级流程、产品和数据标准”，使得开发与运营之间的协作配合难以高效，缺乏整体架构设计的“敏捷开发”仍可能仅仅是“敏捷神话”。
　　Gartner公司所强调的“互联网IT”环境下“敏捷开发”和DevOps无疑是发展前景广阔，但同时也需注意到，采用企业级业务基因组图谱驱动的企业级敏捷开发及其DevOps，较之竖井模式的敏捷开发及其DevOps，能够创造出更高质量、更高效率、更可持续的快速创新和精益运维效应。
　　譬如一些商业银行借助“业务流程组件化管理”技术，搭建起业务流程创新和IT应用架构实现之间的桥梁，大幅度提高了组合产品的研发、分销、交易和管理效率；借助“面向服务的企业架构”技术，创建面向服务、支持创新为导向的、灵活的IT基础架构，使“业务流程、应用架构与基础架构”之间密切协同，实现可迅速组建和配置企业级的、可扩展的业务系统，并实现组件在不同渠道的共享使用。例如涉及客户和员工的数据，不必自己单做一套竖井，可直接从管理客户或员工信息的组件拿数据和流程，技术接口统一，数据共享，在提高支持产品和服务创新效率的同时大幅度降低业务和IT运维成本。
　　如何可持续地提升传统企业IT开发的敏捷性
　　“高度互联世界”的银行IT开发可能遇到最大的挑战，不仅在于业务部门难以扭转从过去竖井式的需求模式惯性转向企业级业务基因组图谱建设，还在于银行IT设计开发人员对企业级业务基因组图谱理解不够，对业务基因组图谱驱动开发方法准备不足，以及实施工艺和业务人员在实施中的参与方式达不到到企业工程的要求。对IT人员而言，关键是要认识上完全完成从传统的信息工程（即所谓的“传统IT”）向企业工程（适应“互联网规模”的“新兴IT”）的转变。下面从国际领先银行IT开发实践辨析信息工程和企业工程的区别，主要有四点：
　　其一：信息工程方法是从具体的业务功能需求到具体的交易服务，即由个性化、差异化的业务需求入手，经过不同的业务功能和界面分析，再进行模块化设计和开发，其抽象化、整合程度主要依赖于开发团队。而企业工程恰恰相反，是先归纳抽象出规范统一的业务规则（即标准化流程和去CPC［客户、产品、渠道］的业务规则）、数据基因组和产品基因组，再描述这些流程和业务规则是如何在不同的客户、渠道、产品上进行个性化和差异化的运用。开发团队是基于整合的业务基因组图谱设计IT系统行为的。例如审核借记卡例子，可能有以下需求：“1、理财卡和财私卡主卡一人只允许申请一张；2、中职卡一人只允许申请一张；3、结算卡的主卡只允许申请一张；4、附卡申请张数小于等于两张……”以往IT开发会依据这原始需求开始设计。而企业工程则会寻找公共因子、提炼业务规则，追求重用。即抽象出“最大主、副卡持有数”作为产品条件，业务规则变为：获取允许持有的最大主、副卡个数；获取客户已持有的主、副卡数；若已达上限则不允许建立新合约。抽象后的业务基因组图谱通过产品条件承载各种变化，业务规则是稳定可重用的；既可以支持快速产品创新，还可以不断增加新规则满足差异化服务的需求。
　　其二，信息工程方法容易造成应用的独立性，经常是麻雀虽小，五脏俱全；而企业工程方法则强调专业与协作，强调不同组件间的信息共享和数据交互，追求“我为人人，人人为我”的境界。数据实体的责任组件就是典型的例子，每个数据实体都有一个唯一的责任组件，一般情况下，只有该责任组件能够创建和维护该数据实体，其他组件只能通过其提供的服务间接访问数据实体，这就要求组件开发时不光要考虑本组件任务的数据服务需求，也要考虑其他组件的数据服务需求。
　　其三，信息工程方法则关注具体的业务或者部门级应用，企业工程更强调从全行角度进行整体设计。在应用架构中主要分为应用和应用组件两个部分，反映的是企业级业务基因组图谱，应用的核心是企业级标准化活动，应用组件的核心是企业级标准化任务。应用、应用组件的需求来源于部门，其目的是服务于企业整体；若理解为仅面向部门、或为部门专用则是片面的。同时，企业工程还强调战略能力的落地，例如，如若市场营销与销售组件的业务目标包括支持公私联动、团队合作等战略能力的实现，那么在实施中就要一方面通过优化客户交互来满足各部门个性化需求，另一方面通过整体设计实现战略能力的落地。
　　其四，信息工程方法对于应用和应用组件间关系定位缺乏企业级对接管理，而企业工程重视从业务架构、应用架构及其概要设计和详细设计层面做好核心应用和应用组件横向串接，每个应用组件项目组需考虑本组件的流程、本组件输出什么数据、从关联组件输入什么数据、与关联组件的流程对接，使得端到端客户体验得以在同步开发或纵向迭代中无缝链接。
　　从上述四方面分析举一反三，在其他行业也不过如此。仅仅是披上“互联网IT”外衣的信息工程模式敏捷开发往往表面光鲜，大多是从单个项目、单个迭代短期看能够快速灵活，在长期看、整体看难以可持续、可重用发展；而企业工程模式下的“敏捷开发”更能适应“互联网IT”的基本导向，其开发成本和运维成本较之信息工程模式下IT开发（无论是否采用敏捷开发方法）均可大大减少。
　　所以，传统的“敏捷开发方法”只适合短流程的小应用开发，而不适合大型企业级新建或转型项目群建设。滥用敏捷开发方法是一件非常危险的事，敏捷开发方法不等于敏捷性，提升敏捷性的方法有很多，要甄别项目特性使用。切实重视“高度互联世界”里“快鱼吃慢鱼”式企业基因组图谱及基因重组能力建设的虚拟化企业，才能以更低的成本和更高的效率适应“高度互联世界”的“生态圈金融”跨界价值链整合和市场竞争。
　　提升企业级开发敏捷性的关键“使能者”是谁
　　成熟度不高或缺乏业务协同能力的敏捷开发缺乏整体架构管控能力，尽管容易实现某些场景开发迅速上线，却有可能导致端到端客户服务流程缺陷或后续整合成本高昂的后遗症。
　　业务基因组图谱、业务架构师、IT架构师及其配套的IT实施工艺是助力“企业级敏捷性IT开发”的“使能者”。“使能者”中有个关键角色是业务架构师，其作用表现在运用业务基因组图谱迅速解析和评估业务需求可行性，确定项目群内各项目目标、边界及其衔接关系，并与IT架构师对接合作，运用架构原则、标准和工具及时校准同步迭代实施的IT开发项目群接口质量，引导开发人员充分运用企业级业务基因组图谱中的CPC、结构化业务规则表等可重用元素，进行灵活配置开发，大幅度提升开发速度和降低开发成本。
　　企业级敏捷性IT开发与项目级敏捷开发的区别是，业务架构师能更及时做出企业级、跨组件或跨项目的业务架构决策，大幅度减少项目级敏捷开发受制于跨部门协商的“折返跑”成本，并随时衔接业务人员确认迭代设计成果的可用性。企业级敏捷性IT开发非常适合于承担金融安全社会责任的商业银行（当然并不限于商业银行），因商业银行的IT开发质量管控必须确保项目迭代开发过程中及时识别、评估并提前释放风险，避免风险遗传到上线。实时智能银行系统是“战略-业务-”一体化的企业级工程，采用的是新的思想和方法，这套思想和方法不单单是系统建设方法，也是银行转型的方法，实时智能的系统设计要体现业务基因驱动开发的转型宗旨。
　　面对“互联网IT”所带来的挑战和机遇，一些国家的传统企业和银行已经开始实践基础设施、企业文化和技术架构互联网化。无论从互联网架构、电商平台、移动平台甚至客户渠道等，诸多互联网公司与传统企业积极合作，并成功组建战略联盟直接颠覆市场游戏规则，在跨界“媒介”融合的价值链“场景”上，灵活运用“客户、产品、渠道、服务”组合创造出基于定位市场的超级客户“体验”，以灵活的方式支持个性化、智能化的“杀手级”应用（Killers app），提高客户黏性。
　　总之，无论对是否主动或被动被划入传统行业的商业银行而言，还是对新兴企业而言，都应避免机械地将“客户、产品、渠道、服务”界定为“传统金融”，并将之与以“场景、媒介和体验”为代表的“生态金融”人为对立起来。应客观辨识披上“IT互联网”外衣的“敏捷神话”，小心踩上“神似”敏捷的“香蕉皮”，只有这样，才能创建高度互联世界靠口碑传播的“杀手级”应用和超级客户体验“传奇”。
　　参考文献：
　　1) Gartner, Mary Mesaglio,Simon Mingay, Bimodal IT：How to achieve digitization agility in an orderly approach,2014
　　2) Gartner, Lessons for the Enterprise to Learn From Web-Scale IT at Facebook Published: 7 March 2014
　　3) Gartner, Web-Scale IT Influences the Market and Enterprises for Cloud Computing Published: 8 April 2014
　　（赵志宏，产品创新与管理部副总经理，管理科学与工程博士，中国科学院大学MBA企业导师。主要研究方向为企业工程、信息工程、银行理论与实践，主要著作有《银行全面风险管理体系》、《银行产品工厂――创新能力评价解析》等。曾任职领域有银行信贷管理、银行风险管理、银行产品创新、银行客户服务体验管理、银行业务架构管理、银行业务模型管理等。 本文摘自《实时智能银行》一书，文章略有删减。本文不代表作者任职机构观点。本文刊载于《当代金融家》杂志2015年第1期）
（责任编辑：HN055）
03/09 07:5303/09 01:4303/08 22:2303/06 20:1703/05 14:1003/05 07:5803/03 09:3603/02 04:36
科技精品推荐
每日要闻推荐
精彩焦点图鉴
　　【免责声明】本文仅代表作者本人观点，与和讯网无关。和讯网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考，并请自行承担全部责任。