1 方法篇-3-愿景驱动的数字化转型规划

1.2 业务战略是数字化转型的龙头

1.3 数字时代，企业需要适时地调整业务战略
1.3.1 引入数字化商业模式
引入数字化商业模式包括改变与客户做生意的方式，改变销售的渠道，基于产业互联网重新定位与行
业生态伙伴间的关系，等等

1.3.2 提供数字产品和服务
example：不仅提供物理的机械产品，还向客户提供发动机运行状态诊断以及维修保养建议等增值服务
1.4 从“5看”入手描绘数字化转型愿景
1.4.1 数字化转型愿景明确了转型将对业务带来哪些变化。愿景是相对稳定的，不会年年改变。愿景是对未来“提纲挈领”的表达，它不会描述一个个具体的解决方案或项目
-·在客户界面带来的变化

• 内部业务运作层面将为企业带来价值·
• 组织将提升哪些关键能力

1.4.2 描绘数字化转型愿景，需对准业务战略，明确客户的体验诉求，关注行业趋势，审视企业自身的能力和与业界标杆的差距，识别数字技术在企业内的应用前景

1.4.3 5看

(1)看战略
在规划工作中，规划团队首先需要解读企业业务战略和商业模式的变化，识别出企业的“新定位、新业务、新模式”，再思考通过什么样的变革来支撑业务战略目标的达成，进而通过一系列变革项目来改变业务运作模式，支撑业务发展和商业成功
(2)看客户

• 企业客户群体的变化。企业与客户做生意的方式会随着客户类型的不同而有所区别
• 企业主要客户的发展趋势和商业模式的变化
• 客户对体验需求的变化

(3)看行业
在行业大趋势下，企业应该顺势而为
(4)看自己
通过价值流给出企业的业务全视图以及价值创造的过程

(5)看技术
要思考数字技术在企业各业务领域的应用前景，并从中发现数字化机会

1.4.4 ROADS体验

• 客户、消费者、伙伴、供应商、员工5类用户
• 针对每一类客户，识别客户触点，畅想在这些触点上分别为客户实现什么样的ROADS体验

1.5 架构蓝图的6个设计原则
1.5.1 以客户为中心，由外而内进行蓝图设计
1.5.2 明确在哪些端到端流程提升业务效率
1.5.3 从内部视角，看从哪些关键环节入手提升业务能力
1.5.4 各部门的责任分工和层级关系要清晰
1.5.5 明确定义全局性工作
1.5.6 体现架构的演进方向
1.6 “一体四面”细化架构蓝图
1.6.1 其实和togaf差不多

1.7 三阶十二步法

2 方法篇-4-用变革的方法确保规划落地
2.1 变革管理实现“转人磨芯”
2.1.1 可见变革最大的挑战其实来自人，关键上是要改变人的观念、意识和行为
2.1.2 　变革管理的“S船模型”

1)变革是一把手工程，需要的是变革的领导力，因此“船模型”的船头是“发展赞助人/领导层的支持能力”，用于引领变革。
2.1.3 洞察“危机”，适时发起变革
马利克曲线

2.1.4 “运动”营造变革紧迫感
变革需要统一意识、达成共识，当人们面临共同的危机、问题和压力时，最容易产生发自内心的共鸣，统一思想
2.1.5 搭好班子选对人

• 变革责任归位，让业务的负责人承担变革Owner的角色
• 选择优秀的业务骨干投入变革
• 数字化转型要注重用户体验，让用户深度参与到变革的过程中
  2.1.6 读懂人心，消除变革阻力
• 变革中的障碍是现实存在的，只有读懂人心才能真正识别阻力根因
• 华为变革影响分析“问”S
  • 谁的观念和习惯需要改变?
  • 谁的利益受损了?
  • 谁的权力变小了?
  • 谁的责任变大了?
  • 谁的工作量增加了?
  • 谁的效率下降了?
  • 对谁的技能要求更高了?
  • 谁的体验变差了?

管理利益干系人，消除变革阻力的5个策略

• 1)保持战略耐心。拉长变革时间以消除大家心理上对“改变”的恐惧
• 2)保障利益。通过适当的利益保障机制，减少变革的阻力面
• 3)通过“快赢”增强变革信心。变革一般周期较长，需要在不同的阶段设置一些“快赢”方案，使参与变革的人不断获得成就感和利益，有效增强变革的信心
• 4)主动沟通，及时关怀。
• 5)教育与培训，帮助各类人员跨越技能的“沟壑”

2.1.7 发展变革同盟军

2.1.8 调整组织和文化，让数字化落地生根
1　数字化转型需要建设与之相匹配的组织能力
1)固化数字化能力的组织需跟随变革过程一起成长，组织能力不是在变革项目关闭时才启动转移，而
是在转型的过程中同步获得。
2)组织的人员构成既要有业务专家，又要有数据和IT方面的技术专家
3)各业务领域的数字化组织要成为承担本领域持续推进数字化转型的责任部门，在领域内构筑数字化
转型的领导力。
2　调整业务组织及文化，适应数字化转型带来的转变
2.2 4.2　以项目方式推进变革，突破转型束缚
2.2.1 4.2.1　“七横八纵”的变革项目管理框架

2.2.2 4.2.2　立一个高质量的变革项目

• 正式立项前先启动预研工作
• 组建一支优秀的项目团队
• 7个反对
  • 坚决反对完美主义
  • 坚决反对烦琐哲学
  • 坚决反对盲目创新
  • 坚决反对没有全局效益提升的局部优化
  • 坚决反对没有全局观的干部主导变革
  • 坚决反对没有业务实践经验的员工参加变革
  • 坚决反对没有充分论证的流程进入实用
    2.2.3 4.2.3　以价值为纲的项目生命周期管理
    项目价值管理方法
• 建立数字化转型价值度量模型，可以从业务结果、能力建设、管理体系完善等多个维度对变革的价值进行度量；
• 项目立项时参照价值度量模型，清晰陈述项目价值，由立项的决策机构依据项目价值对项目进行投资决策、优先级排序；
• 变革项目的价值需在项目启动规模化的IT开发前被锁定，并支持可度量，以在全项目周期进行跟踪和验证；
• 项目阶段的决策主要以价值为依据，如果价值目标确实需要变更，则要遵从既定的变更流程，获得相应的管理层级批准；
• 就变革项目的价值与各方利益干系人形成共识，吸引业务人员与用户主动参与变革；
• 评价项目成败、申请变革激励都以价值为依据。
  1　引入变革价值度量的TAM模型
  

2　以“内部交付契约”价值承诺书(Value Book)为抓手，对变革项目进行评估验收

2.2.4 运营夯实，防止回潮
变革是一个改变行为、习惯、组织、文化的过程，这个过程相对来说是漫长的，需要持续不断的运营才能保证变革成果最终转化为“固有”的组织能力，变成“习以为常”的日常

2.3 变革评估，“第3只眼”看价值实现
2.3.1 　变革评估方法

明确以数字化转型目标为基准，坚持事中评估，并从3个维度评估数字化转型效果，即能力构建
（交付件）、价值实现（业务价值）、使用者视角（用户体验）

能力构建：主要评估项目组承诺的交付件是否按目标完成。
价值实现：评估项目交付后，是否给业务带来变化并产生价值，如业务的效率和效益是否提升、客户体验是否提升
使用者视角：核心是关注用户体验， 是否获得了更好的数字化体验，是否提升了作业效率

3 方法篇-5-视IT为投资，用产品思维管理IT
3.1 5.1　数字时代IT系统的重新定位
3.1.1 转变

• 从“管理系统”到“作业平台”：企业的业务作业、业务运营和决策、团队协同等业务动作已经和IT系统集成，IT系统逐步转变为作业系统。
• 从“功能优先”到“体验优先”：用户在消费互联网的App中所获得的海量信息、一站式购物、流畅顺滑的体验，提高了他们对企业内部IT系统的期望值。企业开展数字化转型，体验也成了需求方的优选项
• 从“重上线、轻运营”到“全生命周期管理”：“数字化只有起点，没有终点”，运维是被动式维持，强调的是稳定可用，而运营则是主动经营，更强调体验和效益
• 从“相对稳定”到“快速响应”：数字时代，业务所面临的不确定性日益增加，IT系统和业务深度耦合，需要快速响应业务变化，甚至推动业务创新
• 从“物理世界的记录分析”到“数字世界的模拟推演”：数字时代IT系统的一个重要特征就是支撑业务在数字世界中探索，通过模拟推演找到最优解，再对物理世界产生影响

3.1.2 把IT系统定位为“产品”
关键就是将研发由技术驱动转变为客户需求驱动的产品投资行为（按产品进行全生命周期管理）
纯研发团队开发的方式转变为跨部门团队协同的方式（一体化协同团队）

IT产品团队由于包含了业务、数据、IT人员，更适合引入服务化架构，使得IT系统由做“功能”变为做“服务”，将一个复杂的IT系统拆分为一个个相对解耦的应用服务，使其能够基于业务场景的变化进行快速优化和迭代，从而更加灵活地响应业务变化。

3.2 5.2　 IT产品的全生命周期管理
3.2.1 问题
由于需求源源不断，交付压力大，所以IT部门往往把交付放在第一位，于是出现了“只管生不管养”的情况：不断建设，但缺乏系统性的规划，也不重视运营。
3.2.2 5.2.1　从被动响应到主动产品规划

• 总结前期产品建设和运营情况
• 获取产品规划的输入
• 设计架构、规划产品特性和路标
  3.2.3 5.2.2　价值与体验驱动的产品运营
  通过运营数据闭环价值，通过用户连接倾听用户声音，基真实、可信、准确的结果数据和用户使用反馈，持续驱动产品优化与创新。
  以价值为纲：树立产品价值观导向，通过运营数据闭环价值，设定价值运营目标，持续监控，发现问题及改进机会点闭环管理。
  以用户为中心：基于用户画像对用户进行精细化管理，对准用户场景，加强线上/线下用户连接，倾听用户声音并快速闭环，提升用户体验

常见误区

• 过于碎片化，不够聚焦：改变自下而上收集汇总价值目标的模式，对准核心业务和核心用户群。
• 缺乏挑战性：根据市场空间（分母）来制订目标（分子），对于已无提升空间或进一步提升代价很高的价值点要及时进行刷新。
• 目标完全和业务挂钩或业务无感知：业务痛点要与IT系统有直接关，如果属于共同背负的业务目标，需要有IT侧的子价值目标作为支撑。
• 难以度量：数据难以从可信数据源获取或因计算口径导致数据跳变。

产品运营分为业务运营、系统运营及用户运营来开展
1)业务层面关注所承载业务的流量、流速、流效。
流量：IT系统承载的业务量
流速：业务运作效率。把一个业务在全流程或者某一段业务所涉及的流程活动、决策评审点、等待时间、增值时间等数据可视化
流效：业务运作效果，包括业务运作质量、差错率、准确率等。
2)系统层面关注产品的服务水平
（如数据服务调用次数）、质量（如页面3秒性能达标率、服务调用成功率、生产环境缺陷率等）、工程能力（如需求实现周期、页面一致性等）
3)用户层面关注用户声音
关注用户体验，分析用户行为，组织用户大会等活动，做好用户经营，从“被动服务”转变为“主动经营”，打造有温度的产品

3.3 5.3　组建业务和IT一体化团队
3.3.1 5.3.1　团队融合：配备关键角色
1　按角色组建业务和IT产品团队

2　落实产品经理负责制
3.3.2 能力融合：业务人员懂IT,IT人员懂业务

3.4 5.4　用V模型指导服务化设计
3.4.1 5.4.1　引入服务化架构
3.4.2 2　评估IT产品的服务化水平

• 数据维度
  重点考量数据模型设计质量、数据一致性和数据服务化情况。好的数据模型设计，是一个
  好的应用设计的基础，高内聚低耦合，很大程度上是体现在数据上的
• 服务维度
  重点考量服务共享、服务质量和服务响应的情况。服务间通过API进行集成与通信，API是
  消费方驱动的契约，服务化后，API的质量关系到应用的稳定性和性能
• 代码维度
  重点看代码规范、超大函数和冗余代码等
• 收入与成本维度
  主要看服务虚拟结算情况、服务成本和硬件成本等

3.4.3 5.4.2　 V模型：从业务到IT的服务化设计方法
V模型以服务化理念为核心，以数据为锚点，将自顶向下的业务设计方法和IT应用的规划及设计方法相结合。

服务化V模型中的关键要素
(1)价值流
有别于业务流程，价值流是对这个价值创造过程的高
阶直观描述
(2)业务能力：业务能力是服务化变革的入手点。数字化转型面向愿景，推动和引导业务模式、组织架构和运营模式
(3)业务场景与业务流程
(4)业务活动
(5)业务对象
(6)应用服务
(7)应用系统模块
(8)产品/子产品：产品/子产品是强关联的一组模块的集合，也是产品团队进行建设、预算、核算、考核、合作分包等管理的基本单元

2　 V模型的具体设计过程示例
(1)确定业务能力
(2)分析业务场景，定义并收敛业务活动
(3)识别BI （business item），定义业务对象
识别每一个业务活动输入和输出的“表、证、单、书”d，定义业务对象。如果一个活动的输入和输出符合业务对象的特征，则可以是一个业务对象。反之此BI不能独立存在，需要继续确定所归属的业务对象。
(4)识别应用系统模块，以及应用服务/特性
3　设计的核心：围绕相对稳定的数据来设计业务和IT