图解CIO工作指南

作者：野春综合研究所
读者：锅巴GG

本书是一本实务手册,系统介绍了企业运用 IT 手段提高竞争力所必需的管理方法和实践经验,主要面向 CIO 等负责企业 IT 运用的相关人士。本书由野村综合研究所(NRI)于 2000 年 2 月初版,之后经过数次修订,如今已经是第 4 版了。本次修订改变了以往的内容结构,将全 书划分为三个部分,并增加了一些新的特色。

读此书也有一段时间了，又到了年底，不仅又拿出来重读了一遍。无他，作为一个技术管理者，光有技术思维在我看来是远远不够的，企业的IT管理是个综合性管理问题，信息技术和信息管理技术，都是扎根于企业的各个单元，不断深入、优化、提升和改进的，在这个过程当中，一定要放眼全局，随时把握业务发展需要，做好适配和调整，支撑好业务。由于CIO的角色更多的是引导者，所以，我觉得技术线的管理者应该需要了解CIO的工作内容和重心，不一定是为了更好的配合，而是在做技术管理工作的时候，能够心存CIO的视角，为更好的支持业务努力。

IT管理

所谓 IT 管理,是指运用 IT 技术提高企业竞争力所必需的所有管理业务。具体包括制定作为企业方针的 IT 战略,以及统筹执行该战略时与 IT 相关的人力、物力、财力、风险等要素在内的一系列管理业务。IT管理具备一些特殊的难点,例如利益关系者范围广(包括企业经营层、各个事业部门、IT 子公司、外部供应商等)、IT 技术发展速度快,以及所管理的对象是无形对象等。

引申阅读：诸如 COBIT(IT 管理体系)、Val IT(IT 投资管理体系)、UISS(信息系统用户技能标准)、ISMS(信息安全管理系统)等众多方法论。

• 阅读心得：

IT管理，首先要明确管理目标。管理目标从何而来？是我们思考的第一个问题。对于企业来说，首先要明白IT的定位，IT的战略定位是来自于企业发展的需求的，是研发为主？运营为主？还是数据驱动？

IT战略的定位

• 与经营战略相吻合的 IT 战略

所谓 IT 战略,是指“为实现企业的经营战略而制定的 IT 运用方针”,因此,经营战略与 IT 战略应该是密不可分的,两者必须保持一致。而确保和维持两者的一致性,就是 CIO 应承担的重要职责。

• 解决经营课题的 IT 战略

不同类型的公司，不同阶段的公司的经营问题不尽相同。如果公司的大部分营业额和利润都依赖于特定的业务,因此“创造新的收益支柱业务”就成为了其经营课题。此外,为了提高业务效率,实现具有成本竞争力的企业运营也成为了一个经营课题。实际 IT 战略一定是服务于公司的经营的。

确保与经营战略一致性的 IT 战略(大型服务企业案例)

IT 战略的概要

在 IT 战略的制定中,应明确 IT 理念 • 愿景、IT 整体方针和系统化方针这 3 项内容

• IT 理念·愿景

明确 IT 能对企业经营和业务部门做出怎样的中长期贡献,以及为实现这个目的的行动方针和价值基准是什么。

• IT 整体方针

基于 IT 理念 • 愿景,分别制定以下方针：

1. 差异化方针
2. 共享化、标准化方针
3. 资源组合方针
4. 管理方针

• 系统化方针

针对“业务应用系统”和“系统基础架构”的实现方式,明确具体方针和重点措施。

IT 战略的制定流程

IT 战略的制定,通常应该有以下三个流程：

1. 把握现状和目标

在从经营层、业务部门和 IT 部门各自的视角把握现状的同时,设定本公司 IT 的未来规划和目标。

2. 整理需求、课题与确保一致性

为了让经营层、业务部门和 IT 部门各自的目标和课题保持步调一致,需要对各部门的需求和课题进行整理,在课题解决的方向性上达成统一意见。

3. 制定、统筹 IT 战略

IT 战略的制定、统筹是 CIO 办公室工作人员的职责,但他们绝不应该成为主角,主角应该是实际执行各 IT 战略的 IT 部门各相关负责人。

CIO 应当是 IT 战略的“引导者”。
并非所有的内容都要由 CIO 一个人来定夺,而应该挑选擅长与经营层及业务部门沟通、解决问题并统一意见的优秀人才,任命其为专职的 CIO 办公室工作人员,由他们与 CIO 一起完成制定 IT 战略的工作。
IT 战略的制定,通常应该有以上三个流程。

IT 战略制定与信息运用能力的强化

信息运用能力高的企业,能够通过将销售信息、渠道信息、客服中心的咨询和投诉,以及网上一般消费者的评价等信息综合起来,为提高业务竞争力和附加价值提供有益的参照。

1. 强化信息运用能力的观点及应关注的信息流
2. 建立信息运用假设的探讨体制

确立 IT 治理

• 确立 IT 治理的意义

所谓 IT 治理(IT Governance),是指为了实现同经营业务战略相匹配的 IT 战略,在企业内部建立的治理体制。通过在企业内部确立 IT 治理,能够让 IT 战略得以合理地制定和执行,为经营业务战略的实现作出贡献的同时提高企业价值,从而形成一个良性循环。

思考题：
确立IT治理的机制是？

• 确立 IT 治理方面的职责分工

• CIO 应积极参与到具体机制的建立工作中,例如设立经营层参加的公司级别 IT 委员会,由 CIO 自己担任主持人并发挥领导能力等。
• 此外,CIO 还需要承担 IT 管理和提供 IT 服务的职责,也就是负责在已确立的 IT 治理机制下,制定 IT 战略,并落实实现战略的计划和步骤。
• 另外,如果非常重视管理与被管理双方的牵制关系,则可以考虑将 CIO 放在管理一方,而在被管理一方设置另一名 IT 负责人(如 IT部长)。

• 确立 IT 治理所需的工作

  • 确保经营业务战略与 IT 战略匹配性的体制
  • 保证 IT 战略朝既定方向执行的监控体制
  • 对 IT 战略执行过程中产生的 IT 风险进行控制的体制

• IT 治理的推进体制

  • 以公司个体优化为目标的治理体制
  • 以集团整体优化为目标的治理体制

• IT 战略与 IT 部门的评估

CIO 应定期评估 IT 战略的执行状况以及 IT 部门的绩效,并向经营层和业务部门进行汇报。也就是说,CIO 通过这种形式,能够确认全公司的 IT 战略达成、执行状况,当产生问题或者经营环境发生重大变化时,也能够与经营层和业务部门共同解决。

1. 评估 IT 战略的进展和执行状况
2. IT 部门的绩效考核

IT 投资·成本管理

• 这部分内容需要在实际中深度思考，仅摘要

IT 投资的特征与分类

不同类型的 IT 投资特征与风险

IT 投资相关职责与责任的明确化

CEO 等经营者、业务部门(用户部门)、CIO 和 IT 部门等,都属于公司里的 IT 投资相关者。对于这些相关者,需要明确其各自的职责与责任。如果职责与责任不明确,则容易产生如 IT 投资无法产生价值、部分优化的系统林立等问题。

通过 IT 投资创造价值的过程

1. 策划阶段:业务部门与 IT 部门共同进行系统策划
2. 设计和开发阶段:风险管理不能放松
3. 运营维护阶段:通过运用系统持续产生价值

关于 IT 投资评估

1. IT 投资组合计划评估
2. IT 投资计划评估(IT 投资判断)
3. IT 投资成果评估
4. IT 投资组合成果评估

IT 投资组合计划的评估方法

1. 投资分配的决定

在 IT 投资的推进过程中,决定投资的合理分配时,首先应分别从投资目的、业务系统、效果产出所需时间等角度对每个项目进行讨论和评估,并在此基础上从整体上决定每个领域分配多少投资额。至于从哪个角度来看问题,应综合经营环境等因素来决定。

2. 投资项目优先顺序与投资总额的决定

收集 IT 投资项目的相关信息,从投资目的、业务系统、效果产出所需时间等视角对投资项目进行评估,并在此基础上决定优先顺序。优先顺序的判断标准一般是与 IT 战略的匹配度和投资回报率等。

个别 IT 投资计划的评估方法

1. 从四个角度来进行评估

我们可以从前面所介绍的战略匹配性、效果合理性、投资金额合理性以及风险明确性四个角度对每个 IT 投资项目进行评估,从而进行综合的投资判断。

2. 着眼于效果产出过程的新型评估方法

将 IT 投资产出效果的过程,分为系统直接产出的效果、通过运用系统所得到的效果以及能够换算成金额的效果三个阶段,从而能够有效把握 IT 投资带来了哪些变化,以及效果是如何产出的。

3. 根据项目情况进行评估

对 IT 投资项目的评估不应该千篇一律,而应根据项目内容来制定适宜的评估方法。

个别 IT 投资成果的评估方法

1. 效果合理性评估

对于每个 IT 投资项目,需要确认其能否达到事前评估所设定的投资回报率。然而,有些项目产生效果需要一定的时间,因此很多企业没有在合适的时机进行事后评估。

2. 投资金额合理性评估

和投资效果一样,投资金额也应当就是否在计划内完成系统开发进行评估。当计划金额与实际金额有出入时,应对造成此情况的原因进行分析,比如对计划金额报价的合理性进行验证,或是搞清楚系统开发范围扩大、缩小的理由等。

IT 投资组合成果的评估方法

1. 投资分配的相关评估

对于整体的投资金额,需要在每个项目的明细上,对计划和实际的偏离状况以及偏离原因进行分析。

2. 投资总额的相关评估

通过追溯历年来实际投资的变化趋势,可以把握 IT 部门的投资执行力。

IT 成本的管理方法

1. IT 成本的范围
2. IT 成本把握的实际情况与发展方向

IT 成本的分析方法

要想实现 IT 成本的合理化,首先必须通过对 IT 成本的把握和分析来实现 IT 成本可视化。可以将 IT 成本按照下述1至4的角度进行分解,通过对年度变化趋势和结构比例变化等进行分析,讨论成本合理化应采取的措施。

1. 按品目划分
2. 按业务划分
3. 按系统划分
4. 按供应商划分

IT 成本的标杆分析

在评估 IT 成本的合理性,对 IT 成本进行合理化管理的过程中,与经营规模相近的其他同行业公司进行比较,即标杆分析(benchmarking)是一种行之有效的方法。

IT 成本合理化措施

根据 IT 成本合理化评估的结果,对于那些判断为成本过高的项目,需要着手削减其 IT 成本。在削减成本方面,可以从 IT 部门的 IT 服务供应管理,以及对系统用户部门(业务部门、后勤部门等)的需求管理两方面入手：

1. IT 部门的 IT 服务供应管理(Supply Management)
2. 对用户部门的需求管理(Demand Management)

对用户部门收费

个人觉得这样似乎不太合理，尤其是会增加内耗，还是算了吧...

IT 资产组合

对于自己公司所开发的系统等产品,应作为 IT 资产进行管理,在保持和提高资产价值的同时,还需要在资产失去价值时做出处理、废弃的判断。

CIO 到底是何方神圣?

CIO 这个职位到底是何时诞生的呢?
第一次将 CIO 在公开著作中作为明确概念提出的,据说是美国波士顿银行的副总裁 William Synnott。
Synnott 在 1981 年撰写的著作中,将 CIO 定义为“针对所有的信息资源,负责确立企业方针、标准以及管理制度的高级管理人员”。
随后,美国有越来越多的企业开始设置 CIO 这个职位。
1996 年,在克林顿—戈尔政权下,联邦政府机构都规定必须设置 CIO 职位。
在日本,野村综合研究所于 1988 年初发表了“日本企业也应当推进 CIO 的设置”这一提议。
受到这个提议的影响, CIO 成为了一个热门话题,同年,日本工业技术振兴协会对美国 CIO 的实际情况进行了调查,并发起成立了日本各大企业的 CIO 联络协议会,因此这一年也被称为日本的 CIO 元年。
尽管 CIO 在日本已经开始稳定发展,但日本和美国的 CIO 在职责上还是略有不同。
根据 2009 年经济产业省的调查,在美国,CIO 的职责重点在于提高 IT 投资效果和削减成本,而在日本则更加重视业务的改革 A。
在沟通方式上,美国大多是以联系经营层和一线部门的垂直型为主,而日本则更多是以致力于协调相关部门关系的水平型为主。
上述结果和 CIO 职业经历的不同也有关系。
美国的 CIO 大多是专职的,出身情况多种多样,但大体上都是由擅长 IT 管理的人才担任该职位。
相对地,日本则多由 IT 以外的间接部门(总务部门、财务部门等)的高管来兼任CIO 一职。
这样做的优点是拥有超出 IT 范围的更宏观的视野,但与此同时,也有很多人因不知如何应对 IT 相关的专业课题而倍感烦恼。
CIO 虽然不必一定是技术专家,但最好是“能够从经营者的视角统管 IT的专业人才”。
Robert Austin 等人的著作《一个 IT 领导人的冒险》(The Adventures of an IT Leader)以小说的形式描绘了一位突然被任命为 CIO的企业高管的经历,可谓是一本面向 IT 管理人员的好教材,推荐大家和本书一起读一读。

IT 组织·人才

这个话题可以在很多书上学习，尤其是管理岗位，这些都应该烂熟于胸。再次不再多谈。

IT 组织、人才相关的探讨课题

资源组织战略

前面提到了 IT 服务提供功能,资源组织战略就是来决定,这些功能哪些通过公司内部资源(人力、物力、财力等)来应对,而哪些则分派给外部的资源来应对。如今,IT 已经与企业的业务密不可分,其内容也愈发专业化、高端化,因此除了公司内部资源之外,还应该对外部资源及其专业性也加以有效利用。

IT 服务管理

• 以业务部门的角度定义 IT 服务

  1. 将业务与系统的关系可视化
  2. IT 服务是业务与系统的接点

• SLA、OLA 的制定与持续监控

  1. 把握业务部门所期望的服务水平
  2. 协商制定 SLA 与 OLA
  3. 定期监控

• 容量与可用性的监控

  1. 容量的持续监控
  2. 可用性的持续监控

• 供应商管理

在 IT 服务的提供中,为了弥补公司人员的能力和人数方面的不足,几乎所有的企业都会利用外部供应商。然而,系统上线后,尽管存在比现有供应商能力更强,或者能够以更便宜的价格提供同等服务的其他供应商,大多企业也不会对供应商进行更换。

• 提高系统改造的效率

• 如今大多数企业已经经历过一轮系统开发,因此现有系统的改造在IT 部门业务中占据了较大比重。这一业务能否稳定高效地运营,是与IT 部门整体业务的稳定化和高效化密切相关的重要课题。
• 此外,业务部门也会提出与现有系统改造相关的各种要求,IT 部门需要判断这些要求的优先顺序,迅速实施改造。

• 系统故障应对

在向业务部门提供稳定的 IT 服务时,系统故障原本是不应该发生的,但实际上我们不可能完全消除系统故障。

• CIO 需要准备对策,使得在万一发生系统故障的情况下,能够将其对 IT 服务及相关业务造成的不良影响控制在最小限度,同时也需要让业务部门理解为上述对策进行投资的必要性和重要性。
• 此外,为了达到 SLA 中所规定的事项,还需要在 IT 部门内部建立应对系统故障的必要方法和体制。

• 查明系统故障的原因并制定对策

• IT 服务的组成信息的统一管理

  1. 明确 IT 服务的组成信息的管理目的和管理对象
  2. IT 服务的组成信息的收集、更新的自动化

• 利用云计算等外部服务时的服务运营

所谓服务运营,是指为业务部门提供的 IT 服务的运营,其内容和水平大多由 SLA 进行规定。除了保证系统的日常稳定运行和降低运营成本之外,将系统的正式环境与开发、维护环境分离,并严格规范对正式环境的访问,确保系统整体的安全性,也是服务运营的重要业务。

• IT 服务的评估、改善和中止

业务部门对于 IT 服务的需求会随着事业环境的变化而变化。因此,IT 部门需要对 IT 服务的使用状况和服务成本等要素进行定期评估,从而与业务部门一起判断是否继续提供该 IT 服务。

IT 风险管理

风险管理是一个独立管理课程，学习的渠道也很多，PMP和PRINCE2课程中也有涉猎，不再赘述。
CIO 需要充分认识到 IT 风险,尤其是信息安全风险和灾害
风险所引发的损失的严重性,并力求提前采取应对措施。

IT 风险的种类及其诱因 IT 风险的分类与定位

IT架构

何为 IT 架构模型

所谓 IT 架构,是指包括业务应用程序、数据、系统基础架构在内的系统整体架构。一般来说,IT 架构既可以单指每个系统的架构,也可以指企业中存在的各种系统的整体架构。类比建筑行业,就相当于单个建筑物的架构,与各种建筑物所组成的城市的整体架构的区别。在本书中,除特别注明外,IT 架构指的都是系统整体架构。

对 CIO 而言,虽然无需深入理解业务应用程序等详细内容,但是有必要准确把握 IT 架构的特点、优势和课题等。
这不仅是为了避免系统因性能不足或使用不便等原因造成对业务的制约,更为了发挥 IT 对业务的牵引和推进作用,IT 架构必须和业务形成紧密的联系。

IT 架构的决定方法

在探讨和决定 IT 架构的时候,可以采用下述两种方法：

1. 以业务改善为出发点的方法
2. 以解决经营课题为出发点的方法

经营课题与 IT 架构模型的对应关系

1. 决定适合解决经营课题的 IT 架构模型

CIO 及 IT 部门应在理解经营课题的基础上,明确为解决这些课题需要 IT 做哪些工作(IT 课题),并提出解决 IT 课题的 IT 措施,然后再决定适合实现这些 IT 措施的 IT 架构。

2. 通过多种 IT 架构模型实现整体优化

• 企业的经营课题往往是几个相互关联的课题彼此重合,并不能单独分割出来一一解决。因此,适合自己公司的 IT 架构自然也无法用一个模型来表现,而是需要将多个模型组合在一起。
• CIO 和 IT 部门需要在掌握公司整体情况的基础上,决定既适合各个地区和业务领域,又能实现整体优化的 IT 架构模型。考虑企业整体的 IT 架构时,需要将针对各个课题制定的多个 IT 架构,从架构、时间上协调匹配并进行组合

能够有效削减成本的 IT 架构

• 成本的削减可分为两类:IT 成本(IT 自身所耗费的成本)的削减和业务成本(业务执行所耗费的成本)的削减。
• 前者包括系统开发、维护、运营所需要的人工费,服务器、终端等设备及软件的采购费,外部IT 服务的使用费,网络使用费,数据中心设施费等。

支持全球化的 IT 架构

提高竞争力的 IT 架构

何为能够长期运用的 IT 架构

在探讨设计阶段,IT 架构应以“根据经营环境、业务需求的变化和技术发展不断改变”作为前提。
为了控制 IT 成本,大家都希望设计和构建一个 10 年 20 年不变的IT 架构,但由于作为其前提的经营环境、业务需求和技术的变化十分迅速,因此这样的设计往往是很难实现的。
在这样的状况下,为了设计一个尽可能长期运用的 IT 架构,应留意以下三个要点：

1. 把握和反映经营、业务计划
2. 把握产品路线图
3. 将 IT 架构的设计思想和探讨过程记录下来

IT 架构标准

IT 架构标准的必要性

以往的大多数系统都是根据经营层和业务部门的要求,通过不断增加或变更个别功能来进行构建的,也就是所谓的个别优化。结果,系统的结构变得庞大而复杂,难以对其进行整体把握。

• 由此而来,很多企业不得不面对以下这样的课题:比如一个简单的错误就会引发严重的系统故障;用系统运行业务时对影响范围的调查和测试周期长、成本高;或是运营复杂,系统老化风险增加等。
• 此外,尽管现在大多数业务都已经实现了系统化,但体现当初设计意图的文件大多未得以保存,业务和系统就变成了一个黑箱。因此,即便想对系统进行重建,也常常会陷入无从下手的局面。存在这样的结构性问题的企业发现,其系统不但未能支援事业,还经常由于无法应对经营环境和事业环境的变化,反而成为事业的绊脚石。

要解决这些课题,可通过下述两点来应对：

1. 对业务规则和业务流程等业务结构进行可视化,与系统架构进行
   整合,并持续维护整合后的状态
2. 通过对系统架构进行适当的管理,防止系统变得复杂僵化

要实现上述两点,需要将系统架构设计得简单明了。因此需要制
定 IT 架构标准,对系统设置一定的制约。

IT 架构标准大体可分为以下两部分：

1. 首先是系统结构标准,它决定了数据处理方式和数据模型标准,通过规范中间件产品的引入,能够对应用程序的开发方式进行制约。
2. 其次是系统要素标准,它对组成系统的硬件和中间件的种类以及版本进行制约。通过制定这些标准,能够一定程度上保持 IT 架构的一贯性,从而控制和减轻系统的复杂化。

通过 EA 实现整体优化

管理企业业务和系统整体结构的“企业架构”(Enterprise Architecture,EA)，EA 是一种将组织的目标、使命、业务运营以及支撑上述要素的系统进行可视化,并制成企业业务和系统整体俯瞰图的方法论。

企业架构(EA)的四层模型

1. 业务架构(BA :政策和业务体系)

政策和业务的相关战略,及其所必要的业务流程和信息流的整体结构。

2. 数据架构(DA :数据体系)

执行政策和业务时所必要的信息处理数据的整体结构。

3. 应用架构(AA :应用处理体系)

业务系统(应用系统)的整体结构。

4. 技术架构(TA :技术体系)

以硬件和网络为代表的 IT 基础设施的整体结构。

实现整体优化的方法

系统的规模越庞大复杂,对系统进行整体优化的工作量就越大。在整体优化中,需要在准确把握公司 IT 资产现状和可用资源的基础上,根据需要起用外部专家,结合专业的手法和工具,提高整体优化的实施效率。整体优化中两个具有代表性的方法：

1. 在彻底改造现有系统的同时引入新架构
2. 配合各系统的维护周期缓慢地引入新架构

难以两全的品质和速度

在系统开发中,系统品质和开发速度之间的平衡经常让人感到头疼。
如果系统能够满足用户的要求,具备适度的功能,且能够稳定运行,这样的系统开发一般被认为是好的,但是对品质的要求越高,开发周期也会相应延长。
因为要开发好的系统,就要尽量毫无遗漏地实现用户需求,从而花费大量的时间和精力。

如今,业务环境的变化十分激烈,IT 部门不但要提供高品质的系统,还需要追随环境的变化,满足业务部门希望系统尽快上线的要求。
在这样的情况下,对于品质的要求应具备这样一种意识,即不必追求完美,而是集中实现对支持目前业务最重要的那些功能。

在新产品和新服务的开发以及新事业的创立方面,有一种称为精益创业(Lean Startup)的手法格外引人瞩目。
这种手法是找出对客户最有价值的最低限度的功能,迅速进行产品和服务的开发,并在开始提供产品和服务之后,根据客户的反馈对其进行改善以及轨道修正、方向转换(在精益创业中
被称为 Pivot)。

在系统开发领域,这种手法也有其应用的价值。
在系统开发时完全把握用户的所有意见是不现实的,对于用户所期望的功能和使用方法,不可避免地需要进行假设和猜测。
因此,即便在需求定义
阶段花费再长的时间,也不一定能够准确判断这个系统对用户是否真正有益。
反过来说,如果将功能控制在最小限度内尽早完成系统开发,通过用户的反应(访问数的增减等适当的指标监测结果)和意见对功能进行改善,反而更容易取得速度和成本方面的优势。

根据 2011 年日本信息系统用户协会(JUAS)的调查结果,在日本的系统开发中,瀑布型开发依然是主流。
尽管这是一种稳扎稳打的开发方式,但根据现今业务部门的需求以及所开发系统的特点,恐怕也需要考虑采用更加重视速度的开发方法了。

实践

这部分内容非常有价值，但是如何运用，真的不是一套固定的章法，仅仅摘取一张图，作为吸引大家阅读的开端吧。

IT 创新的三种类型

化身为创新型组织

要想让创新工作步入正规,IT 部门在构建了前面所介绍的创新“方法论”和“实验室”之后,还需要经过下面所示的三个阶段：

1. 确立卓越运营

所谓卓越运营(operational excellence),即确保 IT 部门最为看重的服务品质、成本和速度,并实行高效的 IT 运营。

2. 通过专业团队积累工作经验和工作方法

下一步是建立一个专业团队,规模大小不是问题。IT 创新工作在探讨流程及所需技能方面与常规的系统开发有很大差异,因此先通过专业团队积累实践经验,再将其成果推广到 IT 部门的其他团队以及相关业务部门的做法是比较有效的。

• 第一,是做出 IT 创新的实际成果。
• 第二个任务,是掌握 IT 创新的方法。

3. 向其他团队和业务部门推广

最后一步,是将上述方法向 IT 部门的其他团队以及相关业务部门进行推广,从而增加 IT 创新的人手。

本书的后记部分非常精彩，建议阅读 by 锅巴GG

---

想加入更多乐读创业社的活动，请访问网站→ http://ledu.club
或关注微信公众号选取：

乐读微信公众号