近年来，“碳中和”的变革浪潮正在冲击着各个领域的企业，这既是对企业的经营管理和市场适应能力的考验，同时也为企业提供了通过自身变革实现可持续发展的机遇。本文从企业在碳中和领域的常规举措分析出发，分析了数字化“碳管理”在碳中和领域如何为企业带来突破；并结合

近年来，互联网上话题的含“碳”量越来越高，例如双碳、碳达峰、碳中和、3060计划、碳交易、绿电等等。越来越多的企业主动或被动的加入到关于“碳”讨论中。绿色、低碳运营都属于企业可持续发展的一部分，对于为什么要开展低碳运营，如何开展，以及何时开展，不同的企业有不同的理解。本文以Thoughtworks的绿色低碳行动为例，详尽分享我们作为一家科技公司在推进过程中遇到的挑战和应对，希望给不同企业的可持续发展之路带来启发。企业需要科学设计碳目标，助力实现碳中和《巴黎协定》于2015年在巴黎气候变化大会上通过，该协定为2020年后全球应对气候变化行动作出安排，中国参与了签署。这一协定的主要目标是将21世纪全球气温升幅控制在比工业化前水平高2℃之内，并寻求将气温升幅进一步控制在1.5℃之内。2020年9月，习近平总书记在第七十五届联合国大会一般性辩论上宣布了中国3060政策和措施：“二氧化碳排放力争于2030年前达到峰值，努力争取2060年前实现碳中和”。这一目标将分解到各个企业，为了帮助企业更好更科学的规划减排目标和路径，由全球环境信息研究中心（CDP）、联合国全球契约项目（UN）、世界资源研究所（WRI）以及世界自然基金会（WWF）共同发起了科学碳目标倡议（SBTi）。SBTi提供了一套科学的减排框架以帮助企业设定更加合理的减排目标，目前，已经有2844家企业通过SBTi加入到气候行动中。信息技术行业应积极行动，发挥独特优势从世界资源研究所发布的2018年各个行业的碳排放分布情况中可以看到，76%的温室气体排放来自于能源行业。而信息技术行业作为能源使用行业，也对温室气体的排放占有相当大的比例；并且随着数字化转型、元宇宙、视频通信、IoT等技术的不断推进和应用，这个比例还在逐年增大（图一）。图一：Thoughtworks的《社会影响力报告》中对于ICT行业的排放统计另一方面，信息技术行业也有着独有的优势，可以在绿色低碳的推进中发挥功效，相关的科技企业可以通过数字化、智能学习、IoT等技术为重能耗，重碳排的行业进行赋能，帮助能耗型企业更好的规划并实现减排路径，以到达全局零碳排放的目标。企业推进绿色低碳时面临的挑战无论是从社会责任角度，还是从商业角度，Thoughtworks的绿色低碳行动都是势在必行的。Thoughtworks一直致力于为客户和社会带来积极的影响，我们相信降低企业运营所带来的气候影响是一家有社会责任感的企业应该去做的事情。随着各国政府在可持续发展方面的要求不断提高，帮助客户加速达成绿色低碳的目标也是Thoughtworks希望能够促成的事情。而企业的减排之路也伴随很多挑战。在实践过程中，我们将挑战归结为以下三方面：减排目标与企业收益之间的平衡。企业真正要达成自己的减排目标，势必需要对现有的运营模式进行调整。如何在不影响企业发展的情况下，设计合理的减排策略，如何将减排目标拆解到企业的运营过程中，是Thoughtworks在实践过程中的挑战之一。跨部门，跨区域协作。Thoughtworks是一家全球性的企业，减排目标的达成需要跨部门、跨区域的协作。但是，不同的区域处于不同的发展阶段，政府对企业的诉求也处于不同的阶段，如何设计合理的协作模式，如何针对部门，针对区域设定减排目标也是在推进过程中碰到的挑战。减排数据准确度。在盘查碳排数据的过程中，采用符合审计的财务数据是最快速的方式。但是财务数据并不能真实反应碳排的情况，比如同样价格的机票，飞行的里程，航线和舱位的不同，可能会产生不同程度的碳排放。因此使用具体的用量数据会让碳排的计算更加准确，也更能指导减排过程。但是获取用量数据是一个需要多部门，多系统协作的工作，同时用量数据是否符合审计需求也是一大挑战。如何在时间，审计，和精准度之间寻找平衡是需要不断考虑的事情。Thoughtworks在应对这些挑战的过程中整理出我们的绿色低碳路径与实践经验，希望我们具有实践意义的“零碳之路”可以为信息技术行业带来更多的启发。Thoughtworks的绿色低碳行动路线Thoughtworks的绿色低碳行动分不同阶段，与行动治理和数字化平台共同构成低碳行动全景图：图二：Thoughtworks低碳行动全景图行动第一步：加入科学碳目标倡议SBTiThoughtworks于2019年加入了“科学碳目标倡议(SBTi)”，向SBTi提交了承诺书。之后，基于SBTi的减排目标设定框架，Thoughtworks开展了碳基线排查，目标设定，减排举措规划等一系列活动。行动第二步：碳基线盘查根据SBTi的要求，Thoughtworks基于温室气体核算体系

本文探讨了我们从新冠病毒造成的大停摆中能够学到什么。文章着眼于我们如何向前发展，避免回到导致不可逆转的全球变暖的「一切照旧」状态；投资者和员工如何推动气候行动；以及企业在可持续的碳排放基准情景（BAU）中应考虑的选择。文章提供了引文和例子，包括可用于帮助规划绿色复苏的具体工具的链接。

本文着重探讨技术领域的多元与包容，某些人面临的新机遇以及很多人面临的一些挑战。文章接着介绍了企业如何在远程工作环境中建立一种包容感，并举例说明ThoughtWorks采取的方法。

我们在第一篇文章中明确指出，技术人员能够为应对当今的诸多挑战做出贡献。许多知识工作者正在高效地工作，他们有能力向深陷新冠肺炎疫情危机的人们提供帮助。但这并不是全部：一种新的特权正在出现，即远程工作的能力。向远程工作方式转变的后果是深远的。本文重点讨论科技领域出现的最新分化，

社会影响力报告第二版——科技、社会与新冠肺炎疫情危机关头，方显企业真正的社会良知，本系列文章分享了我们对新冠肺炎疫情期间和疫情之后科技企业及技术人员的潜在作用的观点。从个人贡献以及如何在有限的时间中有效地履行职责来看，科技产业需要围绕数据、气候和包容性进行思考和辩论。第一篇文章分享了我们利用技术支持社会变革的经验。文章回顾了一些有助于企业充分利用各种支持的要素和实践。文章最后是一个近期实例，讲述了两个团队共同开发开源软件供卫生部门使用的情况。

在前面的文章中，我们了解到新冠肺炎疫情带来的各种变化。最后这篇文章将概述迫在眉睫的社会危机，呼吁针对新冠肺炎疫情暴露出的各种问题深入探讨科技在社会中的作用。文章概述了三项需要实现的转变：将获取技术作为一项社会权利，促进形成开放知识的社会经济，以及普及技术辩论。我们将分享我们各方面工作中的一些小例子。

Ricard）这样的酿酒厂都开始生产洗手液，以超出其核心业务能力的自发创新方式为客户提供价值。COVID-19向我们展示了只要愿意投入

营销是车企运营的重点，但常规的媒体广告，基于价格的竞争在今天越来越难以获得消费者的青睐，数字化营销到底可以做哪些创新，从线上到线下打通与闭环，到越来越多地走出营销原有的边界，从汽车销售商变成出行服务商，我们将通过本篇文章打开创新之门，探讨在一个成熟的领域里如何持续地增量式创新。

在敏捷优先级被提高的当下，银行如何结合自身现状，制定并落地下一步的转型计划以及长期的转型规划，成为了银行敏捷转型的难题。我们结合多家银行敏捷转型的咨询经验及银行业敏捷的现状，提出了银行敏捷转型的三个阶段——交付敏捷、规模化敏捷、企业敏捷。

面对数字化时代的挑战，大型企业都将目光投向了自己的IT（或“科技”）部门，造成IT部门在过去三年时间开始大面积转型。上一波互联网原生企业，如阿里和腾讯，业务直接植根于IT平台之上，创造了多种线上的新商业模式，成为了很多大型组织渴求的目标。而大型组织的IT部门在此之前仍然是成本中心的定位，依靠大量COTS（commercial

经过这一疫，全渠道正式“出圈”了。或许在疫情彻底结束后，各行业企业的数字化能力建设和全渠道体验的优化，将迎来新高潮。对全渠道的再次审视要求我们从更加冷静、落地的角度，思考这个已经有点老了的“新概念”，建立更加立体丰富的理解而不仅仅满足于概念定义层面；更重要的是，需要基于行业先行者经验以及项目实践，提出更有指导意义的实施方法，有效推动全渠道体验的提升。

目录：开放银行基础设施平衡业务价值和开发者体验安全、安全、还是安全API不等于“接口”面向互联网自动化体验API的潘朵拉魔盒API治理全景图API的持续演进API的正确打开姿势面向业务场景设计面向客户持续运营

IT不是成本中心，而应该是利润中心——这几乎成为转型企业的共识。实现这一跨越，从项目制转向产品制，则是必经之路。在产品制开始落地时，第一个问题往往是：到底什么是一个“产品”？一个系统是一个产品吗？一个团队/项目对应于一个产品吗？一个大的特性能不能算一个产品？“产品”的正确边界又在哪里？

直销银行在探索中发展全渠道拓展数字原住民银行将直销银行、网上银行、手机银行、微信银行等，从C端和B端两个层面向非本行用户和金融同业开放，创建开放式网络服务银行平台，实现全渠道向内外部客户的全面开放。

互联网在消费领域的蓬勃发展，让人们看到了互联网企业级应用领域的巨大发展空间。结合国家智能制造、产业升级、振兴制造业等政策红利，推动着企业将眼光投向价值更高、直接付费意愿与能力更强的企业级领域，以期复制“互联网思维”的成功模式，优化产业结构，重构传统产业生态。于是，产业互联网概念也因此应运而生。随着科技进步与发展，以及新型技术应用场景的丰富和消费市场升级，推动移动互联网向产业互联网转移，实现互联网经济下的跨界融合。

随着中国银行数字化转型的深化，通过数字技术洞察客户需求的能力持续提升，银行零售业务已经发生了根本性的变化。客户分析能力的提升也驱动着银行产品和服务迭代速度的加快，随之而来的必然趋势是银行开始寻找新的盈利方式。开放银行作为一种银行商业模式创新的全球趋势，必然成为中国银行数字化发展探索的下一步。开放银行是商业银行数字化转型的重要组成部分，强调以用户为中心，以

中国银行业敏捷转型之大幕已经拉开，“5+12”银行都在大力推进。敏捷与DevOps（研发运营一体化）被理解为相互独立又相互融合的两个概念，在银行业已成燎原之势。在主导和参与了多家大型银行敏捷与DevOps转型后，我们总结提炼出多个行之有效的模型和方法，助力企业快速而有效地启动转型。

无论是世界500强的豪门企业，还是如日中天的互联网巨头，没有任何一家大型组织可以独立具备引领创新价值所需要的所有能力。因此，大型组织都在寻求生态合作，以找到可以形成相互耦合、能力互补的战略合作伙伴。

http://vip.stock.finance.sina.com.cn/q/go.php/vReport_Show/kind/company/rptid/4569689/index.phtml

而是“在看起来都很有创意、很有价值的10个点子”里，挑出2个最突出的让大家做。所谓80%的价值往往存在在于20%的需求里。建立统一的Backlog，永远只找出价值最突出的Top20%给团队做。

March对其定义为组织中开发和创新活动的两者兼顾，因为组织要适应环境和科技的冲击，需要持续不断的创新，开发和探索创新活动同时关注了组织现有能力和对未来的探索，该定义很好地概括了组织二元性的内涵。

近几年，敏捷转型成为了银行转型的标配，从起初的IT敏捷转型，到现在的战略转型为敏捷银行，敏捷在银行转型中的优先级和影响范围在持续提升与扩大。作为敏捷咨询顾问，看到这一现象既欢喜又担忧。欢喜的是越来越多的银行敢于迈出转型的一步，并且找到了相对正确的转型方向（敏捷转型）。担忧的是“敏捷”一词被炒得过热，业界标榜出太多的敏捷成功案例，导致银行开始盲目的遵循标准化的敏捷实践，敏捷转型渐渐地变成了一场形式主义运动，最终收获甚微。在银行转型落地中，我们选了较为普遍的两大维度：组织管理与创新，总结了其中的一些转型误区，同时也分享了改进建议，希望可以抛砖引玉，引发更多的讨论与思考。一.

网点智能化转型过程中，不少银行陷入了“为智能化而智能化”的误区，偏离了便利客户的初衷。通过系统梳理网点智能化现存的问题，有助于银行理性配备智能机具、合理设计机具功能、优化相关管理制度，让智能化回归以客户为中心的正轨。金融科技的迅猛发展全面带动了金融业务的发展，银行网点的智能化转型便是金融科技落地的具体实践。近年来，营业网点向智能化转型成为银行业达成的战略共识，各银行纷纷对网点的智能设备进行大规模投资，通过网点数字化、流程改造实现业务办理离柜化，期许提升业务办理的效率和客户在网点的体验。自助智能机具、网点移动pad等一系列设备也应运而生。毫无疑问，智能化是未来银行网点发展的必然趋势，然而在智能化转型的过程中却看到部分银行为了智能化而智能化，而不考虑自身的客观情况如客户的差异、地区的差异、战略方向的差异等，形成了盲目跟风的状态，最终反而造成了过度的成本消耗。虽然各家银行都在强调以客户为中心，但是在智能化实际过程中却未能给客户带来良好的体验。多数银行更为关注的是业务迁移率、离柜率等运营指标，忽视实际办理场景和流程以及客户的行为差异，造成的结果，往往是网点从自身角度出发完成了硬件设施的智能化改造和相关业务指标，忽略了客户的真实需求，引发客户反感情绪。归根到底，银行需要把握行业变化，更需要理性分析自身智能化现状，回归客户的真实使用场景，才能有效把握网点智能化发力点和突破口。网点智能化困局针对目前银行网点的智能化进程中存在的问题，笔者梳理了5个普遍的“症结”，从源头出发，分析网点智能化这些年都走了哪些“弯路”。1.设备功能交叉流程繁琐银行业务种类的多样性和复杂性在一定程度上决定了设备的多样性，有些是根据业务类型如现金业务和非现金业务进行区分，有些是根据业务环节如叫号、预填单、凭证领取等等进行划分。但是，由于业务的交叉、功能配置的不合理，再加上客户本身对各种机具设备不熟悉，在实际使用中往往倍感困惑。比如并不具备现金功能的移动终端配备了存取款业务，造成了客户先在机具上预处理，进而仍需要排队去柜台办理，流程反而繁琐。可见银行网点对不同设备的定位和业务区分缺乏系统性、人性化的统筹规划。2.客户场景的迁移滞后智能设备研发过程中，银行产品设备部门往往考虑安全性、风险性、技术实现性，但脱离了客户场景。常见的情况是网点仅从业务视角完成了部分业务环节的迁移，但是缺少了客户场景下的功能匹配。比如客户办理取款前往往需要查询余额甚至流水，在大额存款以后往往伴随着转账或购买理财，而在实施中，很多银行仅迁移了部分环节，缺少高频关联业务，造成客户无法便捷地实现一站式完成办理，需要折返到其他渠道进行办理。3.设备数量配置缺乏依据在网点智能化过程中，一些银行对智能设备的投资比较盲目，片面追求网点“智能化、科技化、体验感”，似乎认为网点设备越多客户体验会越好，投入过多没必要的智能机具，没有发挥其应有的效用，造成资源浪费。虽然大多数银行也对网点类型进行划分，如智能旗舰网点、零售网点等，进而根据不同类型和级别的网点进行标准化的设备配置。但同类型网点在不同区域也会存在差异，由于资源匹配的错位，有些网点的设备常常处于闲置状态，而有些网点的客户则在设备后排起了队。造成这种现状的背后，主要是银行在给网点配备智能机具时，没有很好地运用业务数据作为决策基础，导致了资源错配，网点智能化整体效益不高。4.片面强调运营指标为了保证设备的使用率，各银行会对使用设备提出运营管理指标，如通过迁移率来评判设备的使用情况。在制度驱使下，网点人员将指标转化为对客户的硬性要求，比如即便是柜台无需等待，甚至是客户非常抗拒的情况下，强制要求客户在设备上办理业务，给客户带来不佳的体验。又如，银行片面强调离柜率，然而客户类型广泛，不同银行、不同地域、不同类型客户画像的行为存在较大差异。客户如果没有主动学习和掌握操作设备的意愿，即便已多次操作，仍对业务人员百般依赖。尤其是在数字化相对落后的地区，其自主性远达不到银行预期，然而在银行内部对业务办理离柜率要求下，大堂人员不得不一步步辅助客户进行操作，带来的结果，是原来由柜员承担的工作转嫁给了大堂。客户办理业务依然需要排队等候耗费时间，网点的压力依然存在，双方的体验都不佳。（忙碌的大堂人员）5.制度与资源匹配不到位随着网点智能化的推进和业务的迁移，以及服务模式的变化，业务办理的场所将从柜台逐渐转移至大堂，工作重心也将从柜面转移至大堂人员。对比网点智能化前后大堂经理的职责范围，由于业务办理渠道的增多和离柜率的要求，对客户进行合理的业务分流和辅助其业务办理正在成为其大堂人员新的工作重心。柜面业务压力的减小，众多银行已开始尝试逐步将柜员释放至大堂进行业务办理。然而员工角色转型并非一蹴而就，大多数业务仍需依靠现有大堂经理。但对大堂人员的考核标准、权限设置、人员数量、监督培训等并未随着其工作职责和范畴的变化而进行调整，经常出现大堂经理辅助业务办理能力欠缺，或自身权限限制无法辅助办理等情况，影响客户体验。网点智能化瓶颈突破路径针对前文梳理的网点智能化进程中存在的误区与困局，为助力各行网点智能化瓶颈的突破，笔者从智能设备定位、合理配备数量、根据客户旅程优化设备功能以及管理与考核机制的调整四个方面提供建议。1.明晰设备定位不同的设备在设计之初就应有充分的调研和定位，深入理解真实的使用场景和客户习惯。对于已经进入生产环境的设备，银行应及时进行实地走查，对设备建立画像，从客户视角再次评估，定义不同设备主要针对的客户类型、适用的业务场景以及服务方式，对设备进行更加立体化的评价，不断优化不同设备的主要业务和功能。投入使用后期需要根据实际使用情况，对设备进行持续优化。（设备的体系化梳理）同时，网点智能化不应仅仅以追求业务迁移为目标。在进行业务迁移过程中，也并非单纯从员工成本和技术实现的视角出发考虑，需要综合考量客户的行为特征，以及因业务迁移所带来的其他利益相关方（如员工自身）的影响。只有当业务迁移既能提升办理效率，又能使多方共同受益，才能真正带来用户体验的提升，形成多赢的局面。2.理性配备智能机具上文提到，网点的设备配置缺乏合理的参考指标和测量依据。究其原因，主要是对网点进行设备投放时，配置标准较为粗略，无法综合兼顾到不同网点的实际情况，也无法及时对不同网点进行个性化、动态配置，因此设备配置必然会存在不合理性。针对此问题，银行首先应回归投放设备的初心——高效业务办理，也就是说，设备种类应依据网点的业务种类及办理频率差异来判断，设备投放数量需要严格参照网点日均的业务办理数量。当然，过于个性化的测算也会对银行渠道运营提出较高的要求，因此在实施上，银行可通过实地调研和统计各网点设备使用数据，筛选出标杆网点，并以标杆网点为参照（标杆网点意味着其设备使用较为充分，各项指标处于银行期望的标准），计算单台设备业务量基线，以此为标准提出针对存量网点设备配置的计算方法。同时这样的计算方法也为增量网点设备配置提供了数据参考。（网点设备配置逻辑）3.根据客户旅程优化设备功能之前提到，业务办理数字化过程中不仅要做业务的迁移，更重要的是客户场景的迁移。银行在理清各设备的定位基础上，应对各设备的业务承载和深化方向进行探讨，反复优化。同时基于实地调研发现的业务痛点提出新的解决方案。对于可迁移的业务线，需要跳出业务视角，站在客户的立场，挖掘客户在办理某业务下所处的场景，综合考量高频关联业务，避免因业务或功能缺失而带来不必要的跨渠道体验。当然，功能和业务的细化和实施也并非一步到位，遵循敏捷的思维，银行应依据业务办理频次和所带来的客户价值2个维度，对细化功能进行优先级排序，分不同阶段逐步实施落地。（客户体验旅程和实施举措）4.重新定义管理与考核机制网点智能化的核心是为客户带来价值。客户业务旅程中所涉及的各个渠道、人员和设备间的协同对于实现网点智能化核心目标尤为关键。客户分流、业务办理、业务授权等各个环节，都需要清晰的界定负责人员、相关设备和相应操作。这就要求银行系统梳理各渠道间的协同关系，以及不同业务人员在业务办理过程中如何进行配合。员工职责定义、权限优化是第一步，银行需要配套更新体系化的员工服务准则和考核标准，让制度引导行为，以确保网点整体服务体验的提升。另外，网点现有的运营指标体系无法反映客户体验，银行应充分认识银行视角和客户视角的不同，避免片面追求迁移率、叫号量等数据，真正从客户体验出发，综合制定银行自身可衡量的客户体验的标准，削弱指标与客户体验的矛盾。智能化是未来银行网点发展的趋势。各家银行进行探索智能化过程中，理性投资智能设备和切实提升客户体验是各银行面临的挑战，借此文和银行业内人士分享就网点数字化渠道发展的部分观点，期待能带来参考。-

品牌的价值是一种无形资产，但却是产品的内核，产品也可以理解为是一种品牌可视化的传达。因此当团队在提问如何设计VI、IP形象的时候，我们必须还原找到其本质问题——从确定品牌的定位开始。

1971年8月15日，美元与黄金脱钩，世界进入无锚货币时代。1999年1月1日，欧元在德国、法国、意大利、荷兰、比利时、卢森堡、爱尔兰、奥地利、芬兰、西班牙和葡萄牙11个国家正式投入使用。2009年1月3日，中本聪启动了比特币的第一个区块，被称为“创世区块”，最初的50个比特币问世。2019年6月18日，Libra

客户愿景出发：企业需要通过大量的客户调研，理解客户的目标，重新定义客户的愿景，然后从这个愿景出发去思考为客户提供服务的方式，将与这个愿景相关的旅程都整合进来，绘制出价值驱动的全新的客户旅程地图。

多年以后，当我们回顾facebook发币这一事件，会发现其意义远不止一个商业巨头的自我转身。这会是由加密经济掀起的新一轮金融革命，或是滑入威廉·吉布森所描述的赛博朋克深渊？只是身处其中的我们并不知道历史浪潮将向何而去。未来已至,只是分布不均2019年6月18日，facebook公布了它的加密货币计划Libra。尽管项目内部代号GlobalCoin已经极力被弱化，其白皮书仍难掩雄心：“Libra的使命是建立一套简单的、无国界的货币和为数十亿人服务的金融基础设施”。这个时代的互联网和数字化技术已经成为自来水一样的基础设施，将世界不同角落的人们连接起来。与此同时，仍有17亿成年人被隔离在金融系统之外，无法享受传统银行提供的金融服务。联合国2005年提出普惠金融（inclusive

Cash等支付服务相抗衡。银行之间通过结成战略联盟，依托各自资源优势和客户沉淀，通过合作伙伴生态构建竞争壁垒，联合对抗互联网支付巨头的竞争，实现合作共赢，是国内金融机构下阶段可以探索的方向。

如果你有任何问题，请扫描下方二维码提前提出，我们将在直播中进行解答。

Banking）在欧美地区被认为是继FinTech后下一波颠覆银行业的浪潮。开放银行模式的核心本质到底是什么，在中国能落地吗？开放银行（Open

在2015年7月18日央行等十部门联合发布《关于促进互联网金融健康发展的指导意见》之后，创新和规范成为数字金融领域的双重主题。随着互联网公司的金融化和金融服务公司的互联网化，缺乏实力的裸游者的不断出局，产业进入了整合阶段。大多数公司不再梦想仅仅凭着一股山口的风就摇身一变，成为主导型的大平台，而是打着生态战略的旗号，根据自身的禀赋，开展各种异业合作，积极寻求在快速变化的市场格局中重新定位自己。当Capital

新时代的企业需要快速且弹性十足地应对变化中的各种状况，“响应力”来源于创新，通过敏捷和协同发挥其最大价值，拉动企业应对各种变化；“数据力”则是企业发展的新驱动引擎，通过广泛、高效和便捷地运用数据，驱动企业预测变化和持续发展。响应力和数据力是智能商业时代企业必需的能力。未来的智能商业时代充满变化和不确定性，以线性规划和条线化管理的企业越来越难以适应当今的挑战。新时代的企业需要快速且弹性十足地应对变化中的各种状况，不应当再以效率为追求目标，而是应该让自己获得持续应对变化和不确定性的能力。1

产业互联网时代，数字产品的商业模式日趋复杂：B2B、B2B2C、C2B、多边平台等等，客户和用户分离是非常常见的。虽然价值驱动需求是共识，但在复杂模式下，如何确定需求价值，如何做优先级决策，却是知易行难。一些思考，抛转引玉。如果说起产品管理的痛点，大多数人都会提到“确定需求的价值，为需求排优先级”。《产品领导力》一书的作者Richard

反过来，如果你的企业已经被认为是一个“技术即业务”的技术型公司，我认为，中台确实是适合你的。站在这个基础之上，我们可以再来讨论一下，如何正确的构建一个企业的中台，以及如何实施面向中台的战略转型。

为企业构建产品（也称B2B产品，以下我们统称企业级产品）与为消费者构建产品（也称B2C产品），大到商业模式，小到“客户”一词的含义，都会有很大不同。即使你是经验丰富的产品经理，也无法忽略这种差异。

“传统产品管理的时代已一去不复返。数字化业务扩展了产品经理的职责，包括管理创新、召集相关的利益相关者、提升企业的产品战略。数字产品管理的范围已经扩大，因此，IT和数字化业务领导者必须适应这种变化。”

有了定义后，如何建中台的思路也就豁然开朗：如果说中台是「企业级能力复用平台」的话，那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」，再回头看看这两年做的事情，确实也都在围绕着这些展开。

“传统产品管理的时代已一去不复返。数字化业务扩展了产品经理的职责，包括管理创新、召集相关的利益相关者、提升企业的产品战略。数字产品管理的范围已经扩大，因此，IT和数字化业务领导者必须适应这种变化。”

智能商业将给企业带来许多业务升级和转型机会，但是并不是每个企业都能从中获益。如果对智能商业时代的商业环境和竞争态势没有准确的判断，企业内部没有足够的竞争力支撑，反而是企业没落的开始。

这是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务。这种方式，好比是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。

2018对我来说是有很多收获、很有意义的一年。整个上半年完成了一个产品、包括分布在东亚和东南亚三个研发中心的分布式团队转型工作。从上周团队负责人反馈的成效来看，确实给产品的质量和团队的工作氛围带来了提升。我很荣幸能够参与到这个产品和团队的转型过程当中，见证了从开发人员到组织管理层一步步的变化。下半年的工作比较零散，主要帮助了几个团队完成了对当前状态的识别和下一步的规划。领域驱动设计社区的影响力在团队的协作之下进一步扩大，年底的大会对整个社区的实践做了一个全方位的检阅和整理，与企业和国外社区的合作也打下了明年尝试构建更广泛生态的基础。就在刚才，我打开Google日历，回顾了2018年经历的事情和服务过的客户，以及和不同企业、不同层级、不同部门、以及ThoughtWorks同事的每一次沟通，我想可以把我的2018的所思所想，总结成三个我能看到的，并没有那么小的“趋势”。一、数字技术本身，已经成为企业转型和创新的核心引擎回顾过去几年我所经历的企业转型，在转型之初，企业一般都会选择从组织和管理的角度入手开启自己的转型步伐。造成这种选择的背后原因有很多。从组织本身来说比如由于历史原因，组织并不具备技术研发能力，更希望从IT管理侧驱动转型；又比如组织确实具备一定的研发能力，但是由于技术水平有限，希望先通过管理的转型进而拉动技术实践的变革。外部来看，市场上管理领域转型方法论的商业运作及影响力要远远好于技术转型的方法论，这可能也是原因之一。从过去若干年的实践经验来看，管理的转型会前置于技术的转型，甚至管理的转型可能是企业转型当中的唯一一个切片。但在过去几年社区方法论的发展情况来看，技术实践的演进速度要远远快过管理实践的演进。从极限编程到持续交付、再到DevOps，技术实践本身已经超越了所谓仪式（Ceremony）的范畴，逐渐走向真正的“一切Dev说了算”。从企业的具体实践来看，先突破技术的瓶颈，进而逐渐引入管理实践和组织变革，也成为一种可行的转型思路。举个例子，在第四季度我参与了一家日本汽车制造企业的供应链管理变革项目。与我们同时进行的，是该企业集团内部的精益生产变革项目。两个改进小组同时进场，同时开展工作。精益变革小组的改进举措包括了自动化掉现有的人工工作、加强组织间的信息共享和协作等。我们小组的方案是以数据为核心，首先提升数据的质量，利用新技术（区块链等）强化数据的收集渠道，然后通过数据的透明，尽早（8周之前）将供应链的风险与问题暴露给企业，从而加强供应链本身的可预测性和可管理性，进而赋能供应链生态中的日本企业在精益生产方面的诉求。在落地过程中，仍然建议要从管理和组织的维度去变革，来更好的收集数据、分析数据、利用数据指导生产。在这个案例中，过程还是有些波折的。例如处于差异化竞争的考虑，我们一直在避免走到管理咨询的道路上去，但是最后发现如果没有管理方面的配合，即使技术转型的基础搭建起来了，整体上的转型过程仍然可能遇到组织配合和合作的陷阱，使得转型方案没有办法100%落地。但当我们站在企业的角度（要知道日本是精益生产的起源地，大多数客户自身都是精益专家）来看，另外一条精益改进的道路，即从管理的维度逐步展开持续改进，并没有给出一个全局性的问题识别结论和解决方案。这种从管理维度逐步改进的方案，风险可能是经过了一段时间之后发现并没有带来什么效果。对于这家企业来说，像我经历的其他很多企业一样，从逻辑上看风险更低、投资回报比更合理的选项，是让技术变革成为驱动整个供应链变革的核心动力。这个案例给我的另一个启示是，在转型的过程中数据的收集策略和分析策略应该是转型的前置条件。不能说清楚数据上的收益、没有技术手段及时收集和分析数据、亦或不能及时反馈数据上的进展，转型的过程就好像是在黑夜里摸着石头过河。组织活动的开展看上去轰轰烈烈，但是当咨询顾问一走，或者当这阵风过去，一切又恢复到了老样子上。二、业务和技术的融合，成为企业转型的焦点2017年，我的工作重心还聚焦在微服务和敏捷转型上。在那个时候我和我的同事经常会跟客户讲，转型项目成功的关键是能够加入业务部门，让业务人员真切地看到转型的好处。获得了业务部门的支持，转型的影响力就能出来，变革项目也会持久。到了2018年，几乎同样的话我们已经没有机会再主动提出，而客户在第一次或者第二次交流的时候，就会主动问到你们有什么手段和方法可以让业务部门更主动的加入进来，可以让我们的转型得到业务部门的支持。在这一年中，我的另一个主要客户一直在努力寻找这个问题的答案。企业为了追求业务的响应能力，从根本上认识到了机构业务的实质是基于技术提供的服务。基于这个基础假设，该机构打破业务和技术的壁垒，将业务和技术做了重新的整合，实现了IT能力前置，以赋能业务。2018年，我同样很荣幸能够参与到这个企业的转型过程当中，亲眼见证他们是如何重新定义了业务和技术的协同合作方式，并且用新的方式来推进新产品研发的。业务和技术的融合也对技术团队间的合作带来了新的挑战。一般来说，企业除了赋能业务的技术团队之外，还会存在负责企业级支撑和治理的IT团队。如何处理前端业务技术融合团队与后端支撑治理的平台团队之间的协作关系，就又成为了一个新的课题。其实在很多年以前，我还是个新手咨询师的时候，就听到过我的前辈们在和客户沟通平台与应用团队之间的合作原则：做小平台、做大应用。平台做小只实现基本的治理，做大应用提升对业务的响应能力。这个当年似乎是真理的建议放到今天看来，似乎显得不合时宜。阿里的中台概念一抛出，企业都纷纷表示希望引入中台来帮助自己提升业务响应力，降本增效，同时打破数据的壁垒来建立统一的数据中台。2018年，伴随着《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书的火热，中台已经成了国内技术市场的焦点，并且可以确定的事，中台的概念在2019年会进一步的放大和强化。三、架构的转型是企业转型成功的拱心石（keystone）中台概念一出现，一开始我个人的理解是这是一种企业架构治理手段，或者说是企业架构风格的一种新发展。但是经过了几个月的摸索和实践，中台的范围和目标要远大于企业架构的范畴。作为一名领域驱动设计的实践者，分清问题域和解决方案域是基本要求。我认为中台作为一种解决方案，主要解决了企业的三个主要问题。第一、降低企业架构治理成本和开发成本。在之前的企业架构实践当中，治理各个不同业务单元的IT系统建设一直是一个普遍的痛点。企业架构师的很大一部分工作，是来评审各个业务单元所要开发应用的设计文档和实施规划，最终给出一个结论“这个应用是否可以开发建设”。有了中台以后，企业架构师可以将企业级的业务规则，统一封装在中台内部；而将业务应用和创新的职能，以及业务部门内部的应用级规则，交给了业务部门本身。因此，不需要由企业架构师进行统一审核，这提升了企业架构落地的效率和有效性。第二、打通数据壁垒，提升数据利用能力。在以前的企业应用构建方式当中，由于种种原因，各个业务单元的系统之间的数据是很难打通的，或者打通以后反而使得数据质量出现下降，使得利用数据产生业务洞见的效果大打折扣。中台从概念的维度上可以改变这种现状。业务中台可以让企业范围内的数据更有效的收集，数据中台通过数据湖和湖畔市集的建设，利用自服务的方式，赋能业务团队去利用数据来指导业务发展。通过阿里的案例来看，业务中台和数据中台的整合是最大化利用数据的一个很好的方式。第三、降低应用开发的上市周期。中台提供的企业级服务能力，可以让前端的业务团队更快的组织自己的业务应用，并且依据自己的业务目标来规划自己应用的上线周期。而后段企业级业务规则的变化，会被合理在中台范围之内。一旦业务规则发生变化，中台的变化可以独立于应用，并且可以以最快速度在整个企业的所有应用中生效。这也是中台能够给企业级业务带来的最直接的好处。从实现落地的角度看，中台的建设很难脱离三件事。首先，是对于企业级业务规则和企业级服务能力的识别。记得在三年前做微服务咨询的时候，遇到过一个在南京的团队。他们在做的微服务从技术架构的角度来看还是很先进的，但是当我们讨论服务应当如何拆分的时候，就陷入到了复用和可变的细节当中。企业中台的建设也是如此。我们发现很多企业在讨论中台的时候仍然没有去分清“企业级业务规则”和“应用级业务规则”，使得基于复用的中台设计方案看起来边界模糊不清，在落地的时候也会和前端应用团队产生各种合作上的问题。可以预见在2019年，如何去界定中台的边界会是要经常被讨论的问题。我个人仍然认为，在识别企业级业务规则和服务的领域，领域驱动设计（DDD）可以发挥它的作用，帮助企业识别中台的边界在哪里。站在赋能业务的角度看，小平台、大应用的思路仍然是可以工作的。具体平衡点的选择首先要基于最大化的增强业务响应能力，其次是如何使企业业务规则更有效地被执行。其次，中台是难以脱离现有系统，尤其是后台核心系统的架构治理和改造。在过去十几年的时间内，企业都通过不同手段构建了自己的业务核心系统。这种情况从金融行业到电信行业，再到汽车制造行业都是普遍现象。构建中台能力就要求对既要继承现有核心系统的业务规则，又要将核心系统的能力通过服务化的手段暴露出来，变成中台的支撑或者中台的一部分。如何将核心系统从传统的封闭平台迁移出来，以及如何保证架构改造的过程是安全和完备的，这对每个行业的架构师都是一个巨大的挑战。最后，是难以脱离对业务目标和愿景的支撑。中台建设的过程相对比较复杂，既需要对现有系统进行改造，又需要构建中台所需要的各种技术基础设施。这样一个复杂的企业级平台系统的构建过程必然是复杂和长期的。这个过程当中如何引入业务部门，如何在MVP版本的中台中就能够为前台应用带来支撑，如何通过DevOps实践最大化赋能中台的构建过程，就成为中台规划和建设过程中必然要考虑的因素。写在最后2018年下半年开始到现在，我们和几个企业的团队合作企业核心系统的改造工作，主要以金融行业为主。通过架构改造不仅仅可以让后端核心支撑更多的业务场景，同时也提升了企业内部的开发者体验，提升开发效率，我们也在逐渐完善面向传统海量代码（支持Java、C++、和plsql）的架构分析和治理工具，这些都是在尝试为企业中台建设打下一个好的基础。希望在2019年能把工具本身开源出来，同时向技术社区和企业介绍面向大规模金融核心系统的架构改造和微服务化的成功经验，希望能够为更多的企业大型核心系统的改造工作提供工具和案例上的支撑。-

中台战略的成功、能否实现技术架构与组织架构的匹配，是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部，海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。

前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。

中国银行业的数字化转型刚刚拉开帷幕，移动产品成为了中国银行业的新战场。为在新战场占有一席之地，各家银行开始纷纷尝试自己移动产品的敏捷转型，更有甚者开始重新组建IT团队，用敏捷的方式重做原有的手机银行产品。但这些转型往往在6-12个月后显示出明显的疲态。基本的实践都已经导入了，团队似乎已经“敏捷”了，但产品的响应速度并没有变快多少（想法的提出到上线的时长），产品的线上月活也没有显著的提升。那么敏捷转型到此就结束了吗，敏捷转型的下一步我们又该做什么？这篇文章作者将以多个实际案例出发，为大家揭晓银行业的移动产品如何从团队敏捷走向真正的产品敏捷。团队敏捷是必要的，它是产品敏捷的必经之路银行移动产品的敏捷转型很难一蹴而就，团队已经适应了“慢节奏”，习惯了阶段式的开发方式，敏捷的导入，无疑是一场变革。大规模的灌入标准化实践，最后的结果只会是“有形无实”，就像办公室中贴满五颜六色便签纸的白板，最后都沦为装饰品（数周也不更新）。团队敏捷作为敏捷转型的第一步，以了解团队、分析痛点为前提，定制化的导入实践，让团队从传统向敏捷的开始转变。转型团队敏捷聚焦IT研发团队内部，包含产品、研发、测试人员，目标是：打造出一支敏捷迭代运作的IT研发团队建立团队级的敏捷流程及工程方法以及初步形成内部改进的种子力量以50人的手机银行团队为例（4个全功能团队），团队敏捷从开始转型到稳定运作会持续4-8个月的时间。具体的转型过程就不在这里多做论述了。如果您的团队已经满足了以上的3个目标，那么恭喜您，您的团队已经迈出了敏捷转型的第一步。产品敏捷的目标“创业像开车，而不是发射火箭”

（下载完整PPT，或观看PPT详细讲解，请点击文末「阅读原文」）长按识别二维码，下载完整PPT，观看PPT详细讲解

市场的需求当然也催生出了一些所谓“规模化敏捷”框架，如SAFe和LeSS。很多需要解决敏捷大规模应用的组织，于是感觉有了框架和标准。也有很多企业，询问我支持什么样的规模化敏捷框架。

“我这辈子遇到的来自各行各业的聪明人，没有一个不是每天阅读的——没有，一个都没有。而巴菲特·沃伦读书之多，可能会让你感到吃惊，他是一本长了两条腿的书！”巴菲特合伙人查理·芒格曾这样评价巴菲特。

数字化时代企业应当具备什么能力？中短期目标与长期愿景如何协同？创新的基石有哪些？规模化创新需要什么样的组织形式？如何让创新投资能够更快响应市场变化，并最大化投资成效？

题记：2002年3月，《程序员》杂志发表了《极限编程》技术专题。以此为标记，敏捷进入中国已经十六年了。这篇文章是熊节去年为《程序员》写的年终回顾文章，发表于《程序员》2018年第1期。时至岁末，各种年度调查报告渐次登台。其中我注意到云栖社区发布的《2017开发者调查报告》中有一项数据：45.6%软件开发者所在的组织采用了敏捷软件开发方法，在各种开发方法学中位居第一。这个数字又让我联想起，CSDN在年初发布的《2016年度中国软件开发者白皮书》中提到，64%的受访企业采用了敏捷项目管理工具。虽然之前也曾经看到某些调查声称“98%的企业计划采用Scrum”，但我对于这些调查的采样范围一向存疑。云栖社区与CSDN的这两个报告，在我看来客观而坚实地明确了敏捷在当今IT行业的主流地位。作为站在传统企业数字化前沿的咨询师，来自各个行业甲方的动向也给我同样的感知。在电信行业，浙江移动大张旗鼓地开展敏捷转型与DevOps体系建设，并与咨询师结对公开演讲，介绍自己的转型经验。在金融行业，渣打银行的敏捷转型已经进行数年，汇丰银行以敏捷理念构建他们位于西安的研发中心，招商银行的CIO陈坤德在金融科技峰会中正面提出“银行必须敏捷化”，新成立的民营互联网银行更是从诞生第一天就把短迭代、自动化、持续交付等敏捷实践植入在基因深处。在汽车行业，7月发布的《汽车销售管理办法》打破了传统4S店对销售渠道的垄断，乘用车主机厂纷纷上马在线营销或销售系统，欲与已在地平线露头的汽车电商一争高下，短迭代、微服务、持续交付同样是他们在数字化渠道建设中的主题词。在航空行业，海航集团旗下的科技集团把自己转型成PaaS云供应商，组织文化、工作方式全面对标互联网企业，敏捷岛、看板、信息可视化等硬件设施已经成为研发团队标配。看着各行业头部企业的动向，我感到现在已经可以放心地说：敏捷，已然成为不可逆转的时代大潮。这股大潮在中国最初的涓滴潜流，大约要追溯到十五年前。2001、2002年，彼此互不相识的几组人，几乎不约而同地向中文世界引进与敏捷相关的资料。《程序员》杂志在2001年12月专栏介绍重构、2002年3月专栏介绍极限编程，是中文出版物中有案可查的最早的先行者。同在2002年，北京软件过程改进组织（PKSPIN）的成员唐东铭向人民邮电出版社推荐了Kent