终于有时间把稀土开发者大会上讲的「Web 开发引擎」和「低码」话题的分享，改成文字版发出来。 现场演讲中后半部分内容是脱稿讲的，我重写成了更全的内容。 「越来越庞大的应用开发需求」和「现代 Web 开发范式的红利」这两个部分的幻灯片，虽然在其他分享里用过，但在这个话题里，用途是不同的，文字内容是不同角度的，建议不要略过。 分享实录 大家好，我是来自字节跳动 Web Infra 的杨扬。在字节跳动，我们部门负责打造和发展「Web 技术中台」和「前端研发体系」。 上午的主题演讲中，字节跳动正式发布了 Modern.js 开源项目，这个项目的目的是推动现代 Web 开发范式的普及，发展完整的现代 Web 工程体系，突破应用开发效率的瓶颈。现在这个专场虽然是关于低代码的，但我要分享的内容，也是完全依靠这套现代 Web 工程体系，才能够实现。 上午有讲到 Modern.js 是字节内部整套现代 Web 研发体系的三大组成部分之一，我这次侧重讲的，是其中的另一个组成部分：「低代码开发管线」。 议程 低代码是一个很宽泛的话题，如果背景不同、需求不同，解决方案也会差别很大。所以在这次分享的第一个部分里，我们先明确一下这套方案背后最根本的需求是什么，然后在第二部分，我们盘点下各种低码、零码解决方案在这个背景下的瓶颈问题，最后第三部分来看下「全码」通用搭建是怎样的解决方案。先来看看根本需求： 一、突破研发提效天花板 1.1 「越来越庞大的应用开发需求」= ？ 最根本的需求就是应用开发在数量、范围、效率上的需求，大家都知道从 PC 互联网到移动互联网，软件应用被用于更多日常生活场景和更多企业场景，导致应用数量大幅增加，这种趋势到现在不但没减弱，反而还在加强，比如幻灯片上 IDC 的预测，这么庞大的应用开发需求，是很难靠传统的软件开发方式和人才储备来满足的。 最常说的解决途径就是靠低代码、零代码工具，就像幻灯片里右侧这张图，当前市场上存在非常多的这种产品，国内大厂在内部建设的这类项目也非常多。 但这些项目普遍更适合垂直、局部的场景，只支持相对有限的能力。大幅增加的应用开发需求带来更高的多样性、更广的场景和更高的质量要求，其中很多都仍然需要专业开发者的参与，而当前这些低码零码项目又普遍的难以跟专业研发协同工作，所以才会有我们今天的话题——如何跟研发体系结合，突破传统低码技术的瓶颈。 刚才说的这些场景下的应用开发需求，在初始状态下，会完全等同于对专业开发者的需求。我们不应该跳跃思维的直接钻到低码解决方案的牛角尖里，而是应该先站回起点，看看在专业开发方面能提效到什么程度，能满足多少需求，有什么瓶颈，因为低码方案的竞争对手不是只有其他低码方案，而是首先要跟成熟完善的专业研发体系「竞争」。 既然这些场景下的应用开发需求，最初完全等同于对专业开发者的需求，那么显而易见的提效方法，就是让尽可能多的开发者能独立、完整的开发这些应用，而前端技术栈的开发者，正是最大的开发者群体和技术社区。 所以在用户、产品、市场这一侧，一直有趋势和压力，需要更多「前端开发者」成为「应用开发者」或「产品开发者」，鼓励和倒逼着技术领域，不断产生更有利于这种需求的技术形态和基础设施。 不是技术领域，而是商业领域，需要更多「前端开发者」成为「应用开发者」或「产品开发者」，背后的原因除了刚才说的，还有一个，就是随着移动互联网又重走了 PC 互联网时代门户网站、浏览器的老路，除了少数作为领域入口的超级 App，像实体、内容、服务这样海量、高频的需求，都更倾向用 Web 技术来实现，需要前端技术背景的开发者。 研发产品最初是从最接近机器的底层开始发展，从虚拟化，到容器编排，到基于容器技术的各种平台化、服务化的研发工具形态（就像图上绿色部分），这个阶段是后端技术主导的，但整个趋势是越来越向上层发展，越来越接近市场和商业价值最终所在的地方——也就是面向用户的产品，因此必然会发展到前端技术主导的抽象层，让应用开发和产品开发能更专注于用户需求，而越来越不需要关心服务器端的复杂性和专业技术细节。 所以市场需求会趋向于推动应用开发方式往「专注于前端」的方向的发展，「专注于前端」就等同于「专注于用户」，而「专注于用户」是多数企业、产品的根本利益所在。 在这种客观趋势的推动下，基于 Web 技术的应用开发中，服务器端的占比和门槛一直在不断下降。 国内大厂的中台建设，提供了大量不跟特定客户端捆绑、专注于数据需求和底层业务逻辑的 API，让产品开发更聚焦在上层的客户端业务逻辑。 海外流行的 Headless CMS 本质上也是一种中台，也起到同样的作用。 还有 BaaS 和基于云函数的后端云 Serverless，进一步降低服务器端的门槛，让前端开发者能更独立的、端到端的完成产品开发。
但要进一步降低门槛，提高效率，以上模式的一个缺陷就暴露出来，就是他们都把应用依赖的 API，放在应用项目之外维护，跟前端研发是割裂的，这样带来的问题和效率瓶颈很多。还有一个缺陷就是不解决 API 之外的服务器端需求，比如 SSR 等「Web」需求。 要克服这些缺陷，必然需要新的模式，比如明天上午专场会介绍的 Modern.js 中，前端工程方案覆盖了完整全栈开发的各个环节，但同时又通过一体化、尽量无服务器化的方式，实现「客户端为中心」的现代 Web 开发范式。 这些开发范式、开发工具方面的发展，都创造了条件，让更多「前端开发者」成为「应用开发者」或「产品开发者」，工作中也更关注工程，而不像传统前端开发者更关注视觉和交互。 1.2 研发提效的天花板 但无论怎样改进现代 Web 开发体系，改进基础设施，都面临提效的天花板。因为研发效率提升到一定程度之后，就会发现效率瓶颈主要在工作内容本身上面。只要一个前端每周有大半时间要做基础但又繁琐的 CRUD 中后台、临时的活动页面等事情，被这些紧急但不重要的事情占据，或频繁打断，再怎样在研发内部做提效，也改善不了多少。 1.3 「接力」范式 要突破这块研发提效的天花板，就要不局限于研发内部，而要关注软件开发的整个工作流程。然后我们会发现，跟其他创造事物的工作，比如平面出版、摄影、游戏、建筑等，跟这些相比，软件研发的工作流是一个另类。 在这些工作中，掌握领域知识的业务专家，都对真实产物是有了解的，也能直接掌控，比如平面设计师懂印刷、摄影师懂镜头和胶片、建筑师懂材料和施工，大家都通过工具直接真实产物打交道。 而软件研发中，开发者只在少数领域，比如开发工具等，是业务专家，在多数像电商、O2O 等领域里无论如何都是支持型的角色，但软件研发的工作流却是一种独特的「接力」范式，只有开发者才能直接跟真实产品打交道，能真正掌控产品，其他业务专家用再好的工具，产出物都是假东西，比如线框图、交互原型、高保真设计稿，都是对真实产品的一种效仿。工作流中每个环节都有幻灯片上列出的这些痛点，研发提效的天花板，也来自这里。 1.4 「圆桌」范式 游戏研发是垂直领域的软件研发，由于创新多、工作量大参与者多等特点，游戏开发更不可能忍受刚才说的「接力」范式工作流，很值得我们学习。 游戏研发的工作流可以称作「圆桌」范式，真实的代码就是中间的圆桌，所有分工都围着这张桌子，用各种适合自己的工具，直接跟代码交道，产出的都是最终游戏中真实的组成部分，不需要做假东西去跟程序员沟通，等程序员把这些东西用代码从头实现出来。游戏程序员也可以专注于更有价值的事情，实现新效果、新玩法、开发提效工具等等。游戏程序员跟代码交道使用的工具，跟策划和美术使用的工具虽然差别很大，但都来自同一个游戏引擎套件，套件中的不同工具都基于同样的框架、架构、标准。 在字节跳动，Web Infra 有一个「Web 开发引擎」子部门，就是致力于在软件研发领域实现这种以代码为中心的「圆桌」范式。 为了让所有分工都尽可能直接跟真实代码打交道，在同一套「研发管线」里工作，需要专业研发环节有高度抽象的、标准化的工程和工具体系，这也是我们打造和发展「现代 Web 工程体系」 Modern.js 的原因之一。 另一方面可以看到，这次分享最初提出的「越来越庞大的应用开发需求」问题，到这里我们已经明确研发提效能到什么程度，有什么瓶颈，低码解决方案能带来什么帮助，而且更重要的是，这样引入的低码解决方案，是跟专业研发体系无缝结合的。 二、低/零码宇宙之熵 接下来我们看看，为什么需要新一代的低码解决方案，才能满足前面的需求，现有的各种低码、零码解决方案有什么瓶颈。 2.1 RAD 我们逐个看下不同形态的方案，第一个是历史悠久的 RAD 工具。 这种工具有点两极化，一部分开发者把这种工具称作「神器」，有很高的评价，一部分开发者完全不熟悉它们，觉得跟自己没关系，这背后的重要原因是，RAD 工具是要跟特定技术栈、框架紧密结合，才能实现在研发环节中引入低码提效的，所以对不是这个技术栈的开发者没有意义。 这也体现了 RAD 的瓶颈，就是只能面向开发者，无法服务更多不懂技术的用户，满足越来越多的应用开发需求。 2.2 CMS 第二个形态是同样历史悠久的 CMS。 如今 CMS 不但没过时，反而被发扬光大，国内大厂的很多中后台，本质都是 CMS，疫情期间发展很好的美国电商平台 Shopify，也是 CMS。 这种模式的瓶颈问题有两个，一个是更适合配置「内容」，难以解决更多应用开发需求，另一个问题是 CMS 是需要基于模板的，配置的是模板中的可变部分，也跟具体的客户端和服务器端的实现捆绑在一起，让它不可能灵活满足各种需求。 2.3 Website/H5 Builder 第三种形态是近十年来兴起的，由于国内外的差别，在国外流行的是网站搭建，在国内流行的是活动搭建。 他们本质上都相当于 RAD 中偏设计的部分，跟 CMS 的结合体。这种模式突破了 RAD 的瓶颈，让非技术用户能够使用。 但仍然跟 CMS 一样，需要基于模板，基于平台第一方提供的组件库，以及服务器端。这样一方面跟专业研发是割裂的，研发很难提供优化、定制方面的支持，另一方面也是平台锁定的。 2.4 Headless CMS 第四种形态，是同样从 CMS 发展而来的 Headless CMS。 去掉了跟特定客户端和模板的捆绑，只输出 API，可以比较灵活的建模。 瓶颈是，只解决了应用开发的一半，没有客户端，本质上更类似 BaaS 服务。 2.5 aPaaS 第五种形态是近年来大名鼎鼎的 aPaaS。 它是从 SaaS 发展出来的，倾向作为特定 SaaS 的配套，满足企业定制需求，相当于替代了盒装软件时代，像 SAP 这样的企业软件需要专门到企业现场去做的定制开发和实施。 aPaaS 要实现对特定 SaaS 做定制，本质上靠的是后端配置化：把 SaaS 后端业务逻辑的局部做成可配置，幻灯片上的建模和编排是最常见的。所以在 aPaaS 里创建出来的定制版 SaaS，跟原版 SaaS 其实还是同一个应用，后端实现、数据库都在一起。 这些也构成了 aPaaS 的瓶颈：通用性不强，跟特定 SaaS 或 垂直场景捆绑在一起，适合企业软件领域。 2.6 BPM 第六种是 aPaaS 中流程编排的放大版。 BPM 不再跟特定 SaaS 捆绑，而是作为连接器串联大量的 SaaS 和服务。适合企业流程定制。 瓶颈是只能满足这种模式的应用开发需求。 2.7 No Code 第七种是 SaaS 的另一种发展。 像 Airtable 这样的 No Code SaaS，不是在 SaaS 的外部做配置，而是直接在 SaaS 自身的使用中做配置，满足各种需求，把消费和搭建混合在一个界面里。Excel 其实也是这种模式的应用。 这种模式的瓶颈是，在数据能力和界面能力上，都是相对模板化的，不能实现任意应用。 2.8 Design Tools 第八种形态是新一代设计工具，比如 Webflow、Framer 等。 不需要设计稿转代码环节，设计过程本身就在编辑代码产出代码。 这种工具的瓶颈是编辑过程中包含大量设计细节和决策，繁琐，对用户的设计能力有高要求，更适合设计师。但设计师的设计过程是偏探索、随意的，这种工具的编辑器过程更结构化、有更多约束，在设计师中推广也有难度。 2.9 前端可视化搭建 第九种形态不是产品形态，而是国内技术领域常见的概念，「前端可视化搭建」跟「组件库」、「脚手架」，可以并称为国内前端技术团队最常建设的三件套。 就像 aPaaS 是跟特定 SaaS 紧密结合、在这个领域做建模、把 SaaS 的后端业务逻辑做「配置化」，前端可视化搭建也是对垂直领域的前端需求做建模，把前端开发工作「配置化」。 包含「前端可视化搭建」在内的「传统前端技术栈」，可以表示成幻灯片上这样（之前的分享中介绍过），从下往上表示抽象层不断提高，蓝色部分都是前端代码、工程化相关的要素，可以看到「前端可视化搭建」这个红色的方块，跟蓝色部分一样，是从下到上「端到端」的。 这里想表达的意思是，「可视化搭建」的一大瓶颈问题，就是跟专业的前端研发方式彼此割裂。
前面说过「前端可视化搭建」的本质，是把部分前端开发工作转变成「做配置」，所以物料生态、物料开发方式、产物的预览方式、运行方式、发布方式等，都是围绕这种「配置」方式，重新建设一套，跟专业前端的开发方式和基础设施，是彼此割裂的。 很多前端可视化搭建项目，也会设计和开放出来一套「Pro Code」方案，满足用户在搭建中的自定义需求，但这种「Pro Code」跟专业前端真正的 Pro Code 仍然是割裂的。 核心原因跟前面说的一样，为了把前端从「做开发」变成「做配置」，总是需要先针对垂直领域做建模，形成一套配置文件，或配置风格的代码，这里统称为「DSL」，用这套 DSL 替代正常的代码实现，实现能运行这套 DSL 的渲染器，再基于 DSL 实现可视化编辑器。 这种可视化搭建的实现方式，设计和实现都相对简单，门槛低，而付出的代价之一，就是必然跟专业前端的日常研发体系割裂。 围绕这种 DSL 的可视化搭建，在物料环节，必然存在平台锁定的问题。用于可视化搭建的组件，跟专业前端日常开发中沉淀的组件，彼此不互通，降低了组件建设的 ROI。为了在编辑器里对组件做配置，需要为每个组件都去额外开发维护一套配置界面，不管是模板项目的形式、JSON form schema 还是其他形式，都提高了组件的维护成本。以上这些反过来也影响了沉淀和维护改进业务组件的积极性，导致无论专业代码开发还是可视化搭建，物料积累都比较少。 另一方面在渲染、部署环节，不但要专门维护渲染器和平台设施，也导致业务的前端开发同学难以支持和掌控。 物料积累少，建设难，对性能稳定和功能难以支持，都局限了可视化搭建的使用范围和效果。 「前端可视化搭建」跟 aPaaS 一样，都面临两难选择，无论选择专注特定业务和领域，还是追求通用，都会有不同的瓶颈问题，最终结果都是 ROI 不高。 2.10 应用开发领域的「关卡编辑器」现象 前面我们已经盘点了九种低码、零码项目的形态，最后这种不是特定的项目，而是一种普遍现象。 在游戏开发中，关卡编辑器是创作大部分游戏内容的工具，游戏引擎通常自带关卡编辑功能，但很多游戏都会针对自己的独特玩法开发专用的关卡编辑器，一方面满足独有需求，一方面让编辑器更垂直化，提高效率。 低码搭建领域也有同样的现象，很多业务场景都会开发自己专用的低码搭建。 瓶颈问题一方面当然是海量（特别是在国内）的重复建设和彼此割裂，另一方面，在国内（特别是大厂）有很多让这些项目基于一套通用「协议」的尝试，目前为止还没有真正意义上成功的例子，背后的根本原因，也跟前面说的「DSL」模式有关，在这种模式里，「DSL」是天然倾向跟垂直领域紧密结合的，难以通用化。 三、奇点：「全码」通用搭建 盘点了现有的各种低码、零码解决方案的瓶颈。最后来看下现代 Web 研发体系里的「全码」通用搭建，是怎样的解决方案。 在字节内部我们把这套解决方案称作「星夜」。星夜是作为「Web 开发引擎」的一部分，在字节内部验证、发展出来的，适用于任意应用的搭建，它从最初就被设计为完全基于全功能的专业代码，跟包括 Modern.js 在内的现代 Web 研发体系能够无缝结合。 星夜针对的使用者，既有专业的现代 Web 开发者，也有懂技术但不擅长前端开发、现代 Web 开发的人，以及不懂技术的需求方（比如运营、销售等角色）。 3.1 上帝的归上帝，凯撒的归凯撒：解耦「复杂度」 星夜做的事情，首先本质上是在解决软件开发的复杂度问题，对复杂度本身做抽象和解耦，把不可避免的复杂度留给专业开发体系，让低码平台能专注于「业务逻辑的最后一公里」，只负责不需要专业开发者介入的胶水代码。 3.2 「现代 Web 开发」范式的红利 另一方面，星夜也把自己完全建立在现代 Web 研发体系之上，把问题尽可能都交给专业研发体系去解决、抽象，自己只在上层做低码领域的额外建设。研发体系的提效做的越好，星夜就越不需要在上层去用非专业的方法重复解决问题。 实际上这种「全码」通用搭建，也是因为有现代 Web 开发范式的红利，才能够实现的，明天上午的专场会专门介绍 Modern.js，我们这里快速看一下这套现代 Web 工程体系是怎样为「全码」通用搭建带来可能。 3.2.1 从「前后端分离」到「前后端一体化」 在 Web 研发中，最初前端代码「寄居」在「服务器端 Web 框架项目」的里面，随着之后的发展，出现我们称作「前后端分离」的变化，但「分离」出来的「前端项目」本质上有两种，一种是大家都熟悉的 MERN 技术栈，一种在国外经常称作「JAMstack」。 MERN 的字面意思，是 MongoDB、Express、React、Node.js 组合成的技术栈，但这四大组成要素其实都分别代表了更根本的东西，除了 MongoDB 代表的传统 IaaS 和 PaaS，其他三大要素就像图上标注的，都在项目代码内。 可以看到这种项目，本质上是让「分离」出来的「前端项目」，围绕 Node.js 框架去建设，其实还是让整个项目回归成了「服务器端 Web 框架项目」，前端代码还是「寄居」在里面。 这种「前后端分离」并不是真正在技术架构上做了「分离」，而是在「分工」上做「分离」，整个项目是前端开发者自己掌控，但开发方式仍然是以服务器端为中心的。 基于这种工程方案去做刚才说的「全码」通用搭建，就会有大量障碍和成本，比如业务逻辑在前后端重复实现、难以所见即所得的在浏览器端修改和运行完整的代码，等等。这也是「全码」模式以前没有发展出来的原因之一。 另一种类型 JAMstack 的三大组成要素同样不能只看字面意思，就像图上标注的，项目代码内只有纯粹的前端部分，A 代表的 BFF 等服务器端业务逻辑，都在项目之外。 这就决定了对于「全码」通用搭建来说，传统 JAMstack 工程方案的瓶颈问题，除了抽象程度不够，更重要的是「不完整」，服务器端方面的需求，都需要通过在项目之外维护云函数，或自己用服务器端框架开发 BFF 服务。整个应用的业务需求，无法作为一个整体去实现「低码化 / 无码化」。 「现代 Web 开发」的发展趋势，带来了从「前后端分离」到「前后端一体化」的变化，「前后端分离」时期的两种前端工程方案，合并成了一种，可以称作「新一代 JAMstack」，它仍然由三大要素组成，但就像图中绿色高亮出来的部分，这三个组成要素代表的东西，已经发生了变化。 「以 JS 为中心」意味着更成熟的基于编程语言的软件开发方式，而不是围绕「内容」的传统前端开发方式。「一体化 BFF」意味着工程方案现在是「完整」的，可以让应用的业务需求作为一个整体来实现。M 代表的「前端 Serverless」、「一体化 SSR」等，提高了代码部分的抽象层级，让代码更专注于业务需求，减少大量服务器端实现细节。这些变化都有利于「全码」通用搭建的实现。 以一个 Modern.js 的「应用」项目为例，项目是以 src 对应的客户端应用代码为中心来开发的，尽最大可能让开发者不用感知到服务器，不止是部署运维环节，也包括开发环节。 比如这个更简单的 Modern.js 「应用」项目。api 目录对应的 BFF 实现，看上去几乎没有任何服务器端代码的痕迹，可以像普通函数一样设计和实现，像普通函数一样在应用代码里调用（有充分的抽象），但这种代码能实现任意的 REST API，能满足任意的 BFF 开发需求。这也是我们前面提到的「一体化 BFF」。 这个项目中这段包含在 useLoader API 中的代码，体现了前面说的「一体化 SSR」，同一块业务逻辑，只需要一次代码实现，会自动在 CSR、SSR、SSG 等不同情况下运行。并且由于是基于足够抽象的 API 来实现，会在这些情况下自动优化。比如这段代码在独立 SSR Server 中运行的时候，会自动切换成内网方式来请求 BFF Server 的 API，如果 SSR 和 BFF 运行于同一个 Server 进程，会自动切换成真正的函数调用，没有网络请求。 3.2.2 新一代「前端三剑客」
「现代 Web 开发」范式的红利，在「前端三剑客」的演变上也有体现。 「前端三剑客」这个词起源自 Dreamweaver、Fireworks、Flash，对于现在很多前端开发者来说可能已经很陌生了。随着 Web 标准的普及，Open Web 技术中的三个核心要素，HTML、CSS、JS 成为了第 2 代的「前端三剑客」。而自从 Node.js 的出现为前端技术栈普及编译构建工具链、补充服务器端开发能力，前端开发就一直是图上第 3 代「前端三剑客」的模式。 从最早使用字符串模板的 jQuery，到后来的双向绑定、FP 范式的函数组件，都属于第 3 代「前端三剑客」中的视图框架，而三剑客中第二个要素「Node.js CLI」代表了工程化相关，第三个要素是服务器端 Node.js 框架。 而「现代 Web 开发」范式的基础，已经转移到了第 4 代「前端三剑客」。可以看到 Modern.js 正是起到了第 4 代中「元框架」的作用，而「全码」通用搭建，包括我们之前说的星夜，本质上也是在满足第 4 代「前端三剑客」中低代码部分的需求。 可以看到「前端三剑客」的每一代，跟上一代之间恰好都是「包含关系」，每一代中都会有一个要素，把上一代的三大要素包含在自己内部。 背后的原因之一是，随着需求和技术的发展，上一代的「前端三剑客」会越来越难以应对，复杂性不断增加，而新一代三剑客会把这些复杂性和细节隐藏、屏蔽到自己的一个要素中，而这个要素也因此成为新的基础底层，支撑三剑客中另外两个要素，支持各种业务项目的基础建设。 因此第 4 代「前端三剑客」中的「元框架」，起到了第 3 代中 Webpack、React 的作用。而第 4 代中的「低代码」可以在「元框架」的支持下，不再需要跟大量工程细节打交道，更容易实现「全码」通用搭建。 3.2.3 基于「前端技术」的成熟 GUI 软件研发体系 在「现代 Web 开发」范式的趋势下，能形成基于「前端技术」的成熟 GUI 软件研发体系，这对于「全码」通用搭建来说，是非常必要的条件。 传统前端开发中，「DX」和「UX」是不可兼得的。在这种情况下，如果把「低/无码化」做的足够好，提升了 DX，UX 必然受损，导致搭建结果的性能、能力等，跟专业开发的结果有较大差距，或者不够「通用」，无法满足专业开发能满足的所有场景。反之如果保障了 UX，「低/无码化」的目标就会受损，比如无法给不懂技术的用户使用，或搭建过程非常复杂繁琐。 以前面提到过的、极简的 Modern.js「应用」项目为例，只需要配置开启功能，就能实现： 自动 SSR 根据 UA 自动裁剪 Polyfill 根据 UA 自动差异化分发（Differencial Loading）面向现代浏览器的 ES6+ 代码和面向历史遗留浏览器的 ES5 代码 在文件很少、代码量很少、DX 足够好的情况下，也同时实现了很多传统项目中自己写大量代码也没有实现的 UX。 在 Modern.js 的支持下，「全码」通用搭建能针对最少量的、最抽象的专业代码做「低/无码化」，而搭建产物自动获得产品级的能力和性能，不需要自身去解决这些 DX 和 UX 的问题，当然也更不需要围绕垂直场景来解决它们。 要实现 DX 和 UX 的同时最大化，从根本上来说，需要「充分的抽象」，需要「框架」模式。 就像图中左侧，传统前端开发的 DX 和 UX 之所以不可兼得，原因之一是它是基于「库」、「工具」来开发的。最外层的大方块表示整个项目，是蓝色的，代表开发者自己要写的代码，其中嵌入的绿色方块，代表被作为「积木」来组装、在自己的代码中调用的「库」和「工具」。 要支持「全码」通用搭建，需要基于图中右侧体现的「框架」来开发，可以看到整个项目是红色的，是框架本身，而蓝色方块代表的开发者自己写的代码，反而被嵌入在框架的「插槽」中，被框架来调用和组装，开发者自己写的代码成了「积木」。 在专业研发中有了这种程度的抽象，才有可能实现完全基于专业研发体系和真实代码的「全码」通用搭建。 「充分的抽象」也意味着要像 Modern.js 一样，尽可能在所有环节做抽象，不止传统前端开发中常见的运行时环节的抽象（比如 DSL 渲染就是一种运行时抽象），也要在编译时、服务器端运行时、甚至写代码的「编写时」做抽象。 工程方案的收敛和标准化，对「充分的抽象」来说也是必须和必然的，就像以前分享里指出的海量模板问题，如果任意维度有任意变化，都会产生新的样板代码和「模板」，那么基于真实代码去实现「通用」搭建，几乎不可能。 工程方案的收敛和标准化也是 Modern.js 的主要目标之一，目前已经把工程方案收敛到最少的三个，其中的「应用」工程方案，又称作「MWA（Modern Web App）」，是「全码」通用搭建中实现「对复杂度本身做抽象和解耦」的基础之一。 3.2.4 「MWA」：从 Universal JS 到 Universal App MWA 实现了 Universal App 模式。 就像图上梳理的，不论是 SPA 和 MPA 相关的差异，还是实现 CSR、SSR、SSG 之间一体化和混合共存要解决的差异，还是 BFF 业务逻辑跟客户端业务逻辑之间的差异、Node.js 框架之间的差异，以及常规 web、微前端子应用、基于 Electron 的桌面应用、小程序等之间的差异，都被 MWA 抹平，把这些需求统一成同一个「Universal」的「应用」工程方案。 用同一个「模板」就能开发任意需求，同一个「应用」项目，也能以静态 web、SSR、微前端、Electron 等不同方式运行，能同时部署不同形态的版本。 因此「全码」通用搭建只需要实现「MWA」的低/零码搭建，就可以实现微前端、桌面应用、小程序等各种应用的搭建能力。 幻灯片上这个例子，展示的是，任意 MWA 都可以随时成为微前端主应用，并且自动满足其中的 UX 需求。 3.2.5 应用架构 MWA 提供开箱即用的、以客户端为中心的应用架构，对「全码」通用搭建来说，也非常重要。如果没有应用架构提供的标准化抽象，要基于真实代码做低/零码搭建，就要跟粒度非常细、非常原子的、琐碎的底层代码打交道，难以实现好的效果。 MWA 的应用架构让一个「应用」可以由「Universal App Shell」、视图组件、业务模型、容器组件组成，可以基于这些最粗粒度的「物料」来实现「全码」通用搭建。 解耦出来的视图组件和业务模型，可以有多种适合不同场景的「生产方式」，而「消费方式」是标准化的。 容器组件起到 Controller 作用，能用标准化的方式、很薄的胶水代码，来连接视图组件和业务模型。 这些都有助于「全码」通用搭建直接使用专业研发体系的代码，不需要做任何建模和设计 DSL，专业代码本身就可以跟「配置化」的 DSL 一样易于「低/无码化」的编辑和使用，而且具备「图灵完备」的通用能力。 前面提到的「业务模型」（Model），在「全码」通用搭建中是跟 UI 组件一样广泛使用的基础「物料」，可以封装客户端中 UI 无关的业务逻辑，标准化的使用。 3.2.6 「模块」工程方案 「全码」通用搭建中实现「对复杂度本身做抽象和解耦」的另一个基础，是「模块」工程方案。
Modern.js 中的「模块」工程方案让前面提到的视图组件、容器组件（也可以称作「业务组件」）、业务模型（Model）可以独立开发、调试、测试和复用。 Modern.js 也支持「模块」工程方案中的代码，无缝的使用跟「应用」（MWA）工程方案中一样的 Runtime API 标准库。比如创建和使用 Model 的 API、支持「动静一体」的 API 等等。让「模块」工程中的组件不局限于封装纯 UI 逻辑，不局限于「原子组件」，鼓励更多「不同粒度」的业务组件的复用和沉淀，也让「全码」通用搭建在各种场景下都能提供合适的搭建能力和用法。 「模块」工程方案封装了产物方面的主流需求和最佳实践，跟前面说的「Universal App」模式一样，让开发者只需要关心业务逻辑的复用和沉淀，让同一份代码自动适用于各种场景，自动具备各种运行模式（比如 Modern.js 即将提供的类似微前端的「微模块」用法），自动能用于低/无码搭建。 3.3 「全码」：与专业研发体系无缝结合的「低/无码」 前面介绍了为实现「全码」通用搭建创造条件的「现代 Web 开发」范式和 Modern.js 工程体系。星夜作为「全码」通用搭建解决方案，跟前面说的工程体系是无缝结合的， 星夜不需要像传统「前端可视化搭建」一样，通过 DSL 「协议」来做领域建模，因为 Modern.js 本身就是对 Web 开发的最大化的抽象和标准化，这套工程体系和其中的「Pro Code」，本身就已经是一个「协议」。 星夜也不需要另起炉灶搞一套平台锁定的专用 Pro Code 方案，而是跟专业开发者的日常研发完全保持一致。这也让星夜不需要跟特定的 Design System 和组件体系捆绑在一起，可以支持任意 Design System 和任意组件。因此物料的沉淀积累和生态建设也是共通的，避免前面说过的 ROI 问题。 就像幻灯片上画的，这种「全码」模式，不仅解决「输入」侧（比如物料）的问题、带来新能力，也在「输出」侧带来新能力。由于星夜的输出就是前面说的「MWA」，跟专业开发者手写的 MWA 一致，所以除了前面讲过的「Universal App」能力，还带来了新的低/零码提效路径：一个业务项目不用在专业开发和低码搭建之间二选一，不用修改技术栈和旧代码，可以按需渐进的引入低码提效。比如对一些新需求（比如局部页面、局部区域）尝试用星夜来搭建，让开发者逐步从这些需求中解放出去，也逐步积累物料和新工作流的经验，为进一步的低码提效和解放开发资源做准备。 3.4 Code In, Code Out 星夜作为「全码」通用搭建，是「专业代码进，专业代码出」的。不像传统「前端可视化搭建」一样围绕 DSL 设计，而是从一开始就完全围绕真实专业的代码来实现。 在编辑和运行环节，不需要 DSL 运行时、渲染器等，星夜编辑器本质上就是 Web IDE（包括浏览器端沙盒的 Web IDE 和服务器端沙盒的 Web IDE），编辑过程跟 Web IDE 一样加载代码、运行代码、修改代码、生成代码。 编辑器的内部实现中，像 IDE 的实现一样用到各种数据结构和存储，对于「全码」通用搭建，要注意这些内部实现是不应该让专业代码被整体「配置化」的，不能降级成一种领域模型，成为变相的 DSL（这种内部 DSL 也很容易「泄露」出去变成 API）。 星夜编辑器加载和运行的，是全量、完整的项目代码，而「修改」的对象和方式有两类。一类虽然也是项目代码的一部分，但本质是模式化、标准化的胶水代码，专业开发者需要从这种代码的开发工作中解脱出去，这种代码的实现过程是适合「低/无码化」的。还有一类属于「不可避免的复杂性」，应该让专业开发者可以完全掌控，用专业研发体系的完整能力，在 Web IDE 或本地开发环境里手工实现和维护。 3.5 搭建任意应用 「全码」通用搭建带来的最重要的新能力，就是真正能做到「通用」，可以用于实现「任意应用」。 以星夜为例，首先星夜不止是「前端搭建」，既支持「界面驱动」，也支持「模型驱动」（比如 CMS 建模、流程编排、引导搭建等），由于 MWA 是前后端一体化的全栈工程方案，星夜生成的应用代码里同时包含后端和前端业务逻辑，可以独立部署和运维。 另一方面，星夜编辑器就像 Web IDE 一样，只是提供了一个「舞台」，只提供「机制」而不提供「策略」，也就是说编辑器本身具备各种能力，但不决定具体的搭建用法，而是由「物料」（比如 UI 组件）来决定用法。编辑器会根据「物料」的代码、接口描述等信息，自动生成不同的 UI 和交互。 因此任何前端开发者都可以通过开发和维护不同的「物料」体系（比如不同的业务组件库），在星夜上提供针对不同用户类型、不同垂直场景、不同复杂程度的搭建能力、用法、工作流。 由于「全码」通用搭建跟专业研发体系无缝结合，所以专业研发体系能做什么，星夜就能做什么。前端开发者也可以随时直接「介入」星夜中的应用，直接自定义代码满足任意非模式化的、一次性的需求。 列举几个在字节内部支持不同场景的例子。 第一个例子是网站场景，火山引擎官网让产品经理和供应商使用星夜自助搭建和维护自己的产品页面，发布时自动作为微前端子应用，嵌入到前端团队维护的 MWA 工程里，自动用 SSR 方式运行。在星夜中和 MWA 工程中使用相同的官网业务组件库，组件在星夜中的用法，面向不写代码的产品人员设计。 第二个例子是活动场景，运营用星夜编辑器搭建今日头条和西瓜视频端内端外的活动和 Hybrid 界面。使用的组件库、组件的用法都完全不一样，组件中包含跟 CMS（运营平台）相关的业务逻辑。可以看到编辑器本身也有面向这个垂直场景的自定义。 第三个例子是中后台场景，由后端开发者搭建，涉及更灵活的逻辑编排、大型的 CRUD 业务组件，连接自己实现的服务器端 API 等。 第四个例子是数据大屏场景。这些例子中的用法，都是业务部门的前端开发者自己提供的，针对自己工作中的垂直场景做提效，形成解放开发者的新工作流。而星夜这种「全码」通用搭建解决方案，除了普及这种提效能力和工作方式，也追求把这种工作的成本降到跟开发者原本在专业开发工作中做沉淀积累的成本一样（或更低，比如通过物料生态建设的支持）。 3.6 「低码中台」 最后讲一下「全码」通用搭建能实现的「低码中台」模式。 前面讲「应用开发领域的关卡编辑器现象」时有提到过，很多业务场景下开发自己专用的低码搭建平台或在自己的平台里提供搭建功能，是很正常、不可避免的需求。有很多让这些项目基于一套通用「协议」的尝试，目前为止还没有真正意义上成功的例子。「全码」通用搭建由于不受领域建模的限制，基于标准化的专业工程体系，工程体系本身就是「协议」，所以从一开始就能实现「低码中台」能力。 所以星夜的设计、实现和实践验证过程，本身也是在做「全码」通用搭建这种模式的中台化工作和生态建设工作，降低采纳这种模式的成本。 总结 这次分享介绍了现代 Web 研发体系中的「低码 Web 开发管线」和「低码搭建」部分，在研发体系的支撑下，「低码搭建」的新模式和新能力，可以称作「全码」通用搭建。 而图上左边蓝色部分，已经作为 Modern.js 项目开源出来，既希望能加快「现代 Web 开发」中「元框架」和工程体系的发展，也希望通过支持「全码」通用搭建，一方面为专业开发者「赋能」突破提效天花板，一方面推动越来越多有软件需求的全民开发者（Citizen Developer）们获得 「赋权」，在这个「软件统治世界」的时代，让更多人能掌控和解决自己的需求。 Modern.js 目前刚起步，还有很多地方要做到位，期待更多人参与建设和实践。}

袁文泽博客带你用大白话理解什么是数字化转型，为了方便阅读，请关注@袁文泽博客现在我们已经非常清楚，在当今信息时代下，有这么多前沿的科技成果能够给我们企业的数字化转型带来“助力”。看来我们此刻可以大开“脑洞”做一些有意思的事情了！花钱，买设备，铺网线，搭数据库，成立数据部门，高薪聘请数据专家……慢着！切莫太激动了，是不是应该先想想怎么做？先搞清楚状况再开始，数字化可不是请客吃饭这么简单。很多企业都知道数字化很重要，迫不及待地想把数字化这件事“风风火火”地做起来。但是要知道，企业进行数字化转型的风险其实是很大的，企业的核心管理者，特别是决定企业重大战略决策问题的牵头领导，尤其要保持头脑清醒，可别被科技浪潮下的大概念给忽悠得不理智了。图片来自网络决定数字化成败的核心在于对业务的理解，以及在此基础之上的顶层设计和系统规划。在这个过程中，管理者和决策者就得明白到底为什么要开始数字化。要琢磨清楚，启动了数字化项目，企业将会面对什么样的改变。关于数字化的一切都不是单纯的技术问题。或许，这里面涉及大量的技术概念、技术应用、技术成果，但是数字化毕竟是关于业务的，甚至是关于企业战略的。数字化项目的提出要以解决真实的业务需求为目标，应当能够让企业在开展数字化项目之后生意越来越红火，业务规模越来越大，直白地讲，就是能看到好处。我们讨论数字化，实施数字化，其核心就是绞尽脑汁地用技术把我们的业务做得更好，把企业做大做强，这样才是实实在在做事的心态。单纯玩技术，造系统，秀肌肉，无非是做做样子，自娱自乐罢了。盲目的上技术项目，甚至在根本没明白这些技术有什么用的情况下就开始，是非常不理智的。在数字化转型具体实施之前，我们要先做好前期的规划工作，把业务需求弄明白，考虑清楚到底为什么要进行数字化，通过数字化要达到什么样的目标，以及在总体执行层面要沿着什么路线来开展。在数字化转型中，要实事求是，每个企业的情况都是不一样的，因为企业的行业、规模、市场竞争格局都是不一样的，转型不是生搬硬套的事情。在实践中，大企业和小企业的数字化转型思路不一样，传统企业和创新企业的数字化转型思路也不一样。接下来我们就围绕公司业务需求本身，聊聊在开展数字化转型的前期阶段，到底应该怎么进行顶层设计，以及应该注意哪些可能会遇到的问题。在进行数字化转型的时候，首先是要确立转型的目标，确定企业数字化转型的路径和发展方向。尽管对于大多数企业来说，未来数字化转型都是“必修课”，但是在当前阶段，每个企业都面临着各自不同的发展问题，是否下决心进行数字化转型，以及在什么条件和什么时机下进行数字化转型，都应该由企业的领导考虑清楚，计划明白。数字化转型不是人云亦云，也不是别人有我也要有的“赶时髦”。企业不应该为了数字化转型而数字化转型，要明白数字化转型这件事真正会给企业带来什么，最后要达到什么目的。只有这样，在转型的过程中才不会“跑偏”，我们才能真正“触及”转型的意义。数字化的起点是业务需求，有需求才有改变的动力。那么这个需求是谁提出来的呢？有人说，是领导提出来的。但是领导的需求不是需求，那只是要求！需求应该是由用户提出来的，也就是服务或产品面向的最终用户，换句话说，需求应该是由最后“掏钱买单”的人提出来的。用户会说他要什么吗？通常情况下不会，多数用户比较低调。当碰到了问题时，用户大多会含含糊糊地抱怨，不会告诉你应该怎样解决问题，而且大多数情况下，用户什么也不说，只是轻轻走开，“不带走一片云彩”。因此，数字化难就难在不知道用户需要什么，也就是“迈出脚”的第一步最难，这需要仔细思考和调研，也就是做深入的用户需求分析。用户需求分析对于任何企业来说都是件十分头疼的事，所以我们会看到产品经理们每天变着法地折腾，琢磨着怎么把用户脑子里的想法“撬”出来。有了需求，就有了机会，然后才能进行数字化。如果一切安好，就不需要变化。有人说：“不对啊，我的企业做的业务都非常好，产品也受欢迎，市场利润都还不错，为什么还要改变呢？”这个说法没问题，但是经营企业这件事，没有最好只有更好！或许现在你们公司的业务在某个垂直领域已经做到了No.1，但是阻止不了别的企业不断成长进步。如果有一天别的企业提供了更好的服务和产品，同样也会把宝贵的用户流量带走，让你们公司随时失去领先的市场地位！要记住，“真正的竞争者可能在你根本看不到的地方”。所以说，企业的经营者要比用户更了解用户，对市场的判断要有前瞻性，对业务的理解要更专业、更深入。也正是因为这样的原因，组织数字化项目的核心人员，一定得是一个非常非常懂业务的人，这样才能保证整个团队做事“靠谱”。需求不应该是被发现的，而应该是被创造的！需求应该是厘清了业务本身的逻辑和现状之后被设计出来的，这可能是先挖坑再填坑的过程。不一样的地方在于，填完坑之后路比之前更好走！例如，你可能发现在公园门口排队买票这件事儿特别的麻烦，排队过程枯燥无聊，影响游园心情，而且疫情防控期间聚集扎堆特别不安全。于是，你在公园自营的微信公众号入口处添加了在线预约买票功能。游客在去公园游览之前只要在网上简单输入一下个人身份证信息，选好入园时间，在自动跳转到的支付页面付款，就可以直接刷身份证入园了。这件事对公园、游客来说，都非常方便。游客一天能多玩两个项目，公园管理部门也能有余力安排两个员工售卖“网红冰棍”哄小朋友了。但是在整个过程中，应该没有哪个游客主动要求这么做。如果没有特殊说明，大家就一定会“机械式”地直奔售票处排队，低头玩手机等待。在某个现实的业务被数字化之后，除在业务环节中多了“信息系统”（比如微信的购票公众号）这个要素外，原本的业务流程也会发生很大变化，因为整个底层的业务逻辑变了。现实中“矛盾”的是，用户实际上是不会超出原有的业务逻辑提出需求的，因为他们已经习惯了“老”模式，改变“游戏规则”那是商家需要认真考虑的事。业务需求明确了，我们就可以回答“数字化项目最后应该实现什么目标”“数字化过程执行后会产生什么影响”“转型最后会发挥什么市场作用”这些关键问题了。这个需求能够指引着实施数字化项目的团队不走弯路，相当于有个“监督”的标尺来衡量大家是否已经做好了该做的。“不忘初心”很重要。明确需求，并且决定数字化项目执行的负责人，脑子里要一直记着这个需求并朝着这个需求做，才能“方得始终”。业务需求的指定是目标层的事，方向大于努力！有了业务需求之后，才是产品需求，这一层面的需求更多关注的是执行层的任务。例如，我可能想采取一个方式让用户在线预约入园，那么产品需求就需要回答下面这些问题。入园预约系统是放在微信服务号里还是放在小程序里？如果确定了放在服务号里，那么服务号应该进行什么改造？是在服务号里面设置一个快速购票的链接，还是在“入园服务”栏里添加一个预约购票的按钮？预约购票需要让用户填写哪些信息？用户的个人信息会自动填写吗？购票时要不要发送验证码验证？系统支持购买多个人的门票吗？等等。从业务需求到产品需求的转型环节，技术人员逐渐开始参与。基于产品需求，技术人员会根据开发经验、成本、设计理念、产品理念来对数字化项目中的系统开发工作内容进行综合评估，并进行技术系统的具体设计。同时我们可以看到，数字化项目可不仅仅是开发一个系统这么简单，系统只是一个载体，所有的一切都要围绕业务开展。业务变了，任何事都会跟着变。在实施了某个业务的数字化之后，用户会感觉不一样，而实际上，公司内部的员工会感受到更多的变化。数字化转型通常会“牵一发而动全身”，动作稍微大一些的数字化变革，都会对公司里不同职能、不同层级、不同环节的人和部门产生巨大的影响。业务规则本身可能需要重新设计，组织架构可能也会调整，公司内部的配套资源可能会有新的侧重，业务人员的考核方式可能会有变化，或许有些人、有些部门的人力组织构成也要变一变。很多传统企业几十年如一日死气沉沉，一个数字化项目下来，也许就全“焕然一新”。这也给很多新生代的职场新人带来更多发挥自己特长并担当重任的机会。开展数字化项目切记“不要跟风”。不要因为别的企业推数字化项目自己也盲目开始，在做事情之前，要明确目标，数字化不是面子工程。数字化是要花钱的，一般的中型企业如果要进行彻底的数字化转型，则投入一两千万都是少的。更何况，这里面所有因为数字化导致的业务变化，意味着抛弃了原有的可能已经比较顺手的业务模式，那么公司就要面对非常大的不确定性风险。数字化有好处，但是远离舒适区，就必须承担风险！特别地，对于影响比较大的数字化转型工作，需要将其当成公司的发展战略问题来对待，而一旦升级到战略层面，就不是小事了。任何做这个执行决定的负责人都得做到足够谨慎和理智，保持一个科学对待的做事态度。前面提到，业务需求决定数字化的目标。做事情时，应该将目标放在第一位，目标是项目开展的收敛条件，并决定如何评估项目的开展效果及项目的执行方向。目标这个概念很大也很虚，具体来看就是要考虑数字化是否实现了价值的增加！这点要牢记。只有带来价值的工作才是有意义的，而这里所说的价值，要么是降低了企业的运营成本，要么是提高了总体的收益水平，也就是人们经常说的“降本增效”。有些企业花了几千万建设云平台，并且布置机房专门码放硬盘，甚至还会配上“大数据综合业务监控大屏”。年底总结的时候，企业负责人非常开心，觉得自己的企业终于“衣着体面上档次”了，自信地认为数字化转型很成功。但实际呢？云平台大多数时候是关闭的，开启时也没人用，没准还会被一些人员钻空子做私事；金光闪闪的硬盘阵列里都是杂乱无章、无人问津的脏数据，没人看得懂，也没人用；监控大屏动画花哨，可以实时监控业务进展，但是展示的是一些大家都知道的数据指标，到最后工作该怎么做还是怎么做，一切照旧。参观人员前脚刚走，展示大厅就“关机锁门”。大多数数字化项目最后可能会“沦为”讨喜的面子工程，烧钱不赚钱，最后数据部门和技术部门携手来“背锅”。然而，数字化好坏跟它们又有什么关系呢？从来没有听说过数字化项目不成功是因为代码写得不好，更多的时候这件事从“根子上”就做歪了，从头到尾就没有按照“价值增加”的逻辑办事。价值增加这个标准会引导整个数字化的设计，并且价值增减也是需要综合评判的，这背后是综合复杂的战略问题，数字化的顶层设计者要认真地权衡引入数字化技术后企业内外部利益发生的变化。数字化项目的价值评估是一个复杂的预测问题，一旦确定了要执行一个数字化的项目，管理者就得有充足的想象力来判断未来将会发生什么，并且考虑清楚在将要面对的一系列不确定场景下，怎么保证对数字化转型项目的投入产出比是正向的。例如，我准备开展一项“网约车”的数字化业务，那么事先得考虑清楚有了“数字化出行”之后，消费者会不会对这个新的交通出行方式买单，会有多少人接受，这个市场的潜力有多大，能否覆盖推广数字化服务的运营成本，传统的出租车司机的工作会不会受影响，会不会遭受严重的抵制，那些无法适应数字化出行的传统用户怎么办，业务上线有没有舆论压力，用户的出行隐私又怎么保证，人们在渴望便捷的同时是否会接受隐私泄露的风险，等等。图片来自网络这些问题都需要提前进行认真的分析和判断，然后评估数字化项目是否可靠，要不要开展。因为有不确定性，就要承担必要的风险。然而现实是，数字化的回报往往是有延迟的。在真正感受到数字化的好处之前，所与人都是“战战兢兢”的，生怕选错了方向，既浪费时间，又浪费感情。对于很多企业来说，数字化转型意味着二次创业。不进行数字化转型，怕被时代抛弃；进行数字化转型，又担心踩坑。很多企业历经艰辛好不容易“上岸”了，谁又想再掀“风浪”，去折腾呢？这也是很多数字化项目难以推动的原因，决策者看不清方向，犹犹豫豫。传统业务本来做得挺开心的，为什么非要给自己找麻烦呢？很多数字化项目经常开展到一半发现没成效，就又稀里糊涂地回到老路上去了。有的数字化项目根本就是“换汤不换药”，虽然上个新系统，但做的还是老业务，把数字化降级成信息化来做，或者干脆当成硬件采购项目来做。有人说中小企业不好开展数字化，大企业开展数字化容易出成果，但其实这里面各有各的瓶颈。对于中小企业来说，问题主要是数据和技术的积累不够，数字产品的技术形态不好设计。而对于大企业来说，主要的压力可能来自业务架构和组织架构的巨大变化，船大了不好调头，大企业的数字化意味着更高的风险！在很多失败的案例中，大企业“斥巨资”上线了系统，但是这个系统内部员工不爱使用，外面的消费者也不愿意买单，最后数字化项目的牵头人“两头受气”。推动数字化转型的核心人物既要有能力，也要有魄力，当然最重要的是遇到风险和阻力的时候依然能够具有坚定不移的执行力。用户总是很神奇的，你永远捉摸不透他是否按照套路出牌，有时候数字化业务明明设计得挺好，用户也竖起大拇指，但就是没人掏钱，让人彻底没了脾气。设计数字化业务就得能对复杂的市场变化进行精准判断，尽可能地降低业务变化带来的风险。在实践中，对于大企业，可以采用分批次推进的策略，这样做在一定程度上可以缓解数字化转型的风险。饭要一口一口吃才不会被噎到！既然大企业的业务复杂，数字化牵连环节多，那就慢慢来呗，先做试点，然后推广之。先在某个业务团队做，然后到某个事业部或某个子公司试试，最后推广到整个集团公司。在数字化转型过程中，新老业务线会有一段重合，最终的转型需要“软着陆”，不然“撞伤”了就很麻烦！比如说，华为早在2016年就已经开始进行数字化转型了，对于这么大体量的一家老牌技术企业的转型工作来说，就是通过“分步走”的方式来展开的。在具体执行方面，华为以交易流和供应链作为单点业务环节，率先突破，并以此作为试点项目，成功地引起了其他部门的兴趣。慢慢地，当每个业务部门的主管都想要推动数字化项目的时候，再由变革管理委员出面协调各方面的转型资源，实现整体的转型推动。在示范效应出来后，一旦让人看到了好处，数字化工作也就会自己推动着向前发展。决策者过于迷信数字化也是比较“危险”的事，这种情况很可能导致高估技术本身的能力，误以为某个数字化项目能解决所有企业问题。有时候，企业发展的痛点根本就不在于缺少“有用”的信息技术，真正的问题可能来自企业资源的组织方式、产品的质量控制、文化、股权架构、资金链、人才结构，以及市场定位等企业管理经营的其他方面。很多企业遇到的问题既需要技术上的解决方案，也需要管理上的解决方案，两者是分不开的。技术只是其中的“点”，要把技术的点和管理的点连接起来，交织成面，才能真正“兜住”问题，创造价值。以价值增加来引导数字化业务的设计，不是为了做技术而做技术，不是以技术的优劣、是否先进、是否复杂及是否有难度来评判一个数字化项目的好坏。这件事甚至与公司在技术上投入的财力也没有太大的关系。当某公司想增加用户购买产品的黏度时，比较好的方式是在App购物界面上加入一些“游戏化”的场景，比如“种树”“消消乐”这样一些可以反馈购物金币的小游戏，好玩又能拉来新用户，开发成本可能还不到一万元。但如果走错了方向，非要花几千万开发AI算法集群来进行产品和广告的自动推荐，就完全得不偿失了。其实，数字化的难点不在于技术，而在于如何用好技术实现价值的显著增加。我们要充分结合数字化基因，进行顶层业务的逻辑规划，也就是找到数据中能够提升价值的那个“点”。能带来实际价值收益的数字化项目才是“高级”的项目，千万别对高级有了误判，平和大气才是真正的高级，技术上的“网红”是不长久的。进行数字化转型，时机很重要。把握住了时机，恰逢其时，事半功倍；错过了时机，不仅陷入泥潭，还可能得花费几十倍甚至上百倍的力气来“补课”——市场不等人。对于一个企业来说，哪些时机因素会影响领导者做出数字化转型的总体决策呢？一是行业格局发生巨大变化。很多企业通过数字化转型或与生俱来的数字化形态，已经取得了巨大的市场竞争优势。例如，电商平台的崛起，对传统的线下商超或便利店形成了降维打击，让更多的销售发生在线上的交易渠道。这种方式，很可能会“倒逼”传统零售行业企业进行数字化转型，以缩小与携带着强大数字基因的竞争者之间的差距。二是传统的业务模型已经出现了增长极限。行业内部竞争激烈，企业正在寻求新的利润增长点，并研究如何开发新的业务蓝海。例如，在很多从事服装生产的企业都专注于大众头部需求，靠价格优势或在衣服材质上下功夫来获取品牌竞争力时，基于数字化的解决方案或许给我们提供了新的经营思路：服装企业通过大数据分析网络上的社交流量数据，实时获取当下受年轻人追捧的最流行的元素，将其纳入新的服装款式设计中，增加爆款的概率；服装企业还可以让消费者在基本款服饰上设计自己喜欢的时装元素，将订单管理系统、生产计划系统、生产设备，用互联网全部打通，让服装制造厂商可以轻松地做到“柔性生产”，通过让消费者的个性化需求得到充分满足来获得市场优势。三是企业的运营活动低效，面临生产力的升级和改造。例如，对于部分地区的患者来说，医疗资源缺乏，医院线下服务有效覆盖的患者群体可能比较少。患者排队问题、挂不到号问题、医患之间信息不对称问题、患者健康管理问题、疑难杂症诊疗问题、事故责任划分问题、远程治疗需求问题、人员与手术室调度问题等，都需要得到有效的解决。目前，很多医院正在寻求增加医院运营线上化、自动化及智能化程度的数字化解决方案。四是市场上出现了比较成熟的新技术，成为业务升级改造的催化剂。深度学习算法、云计算、5G、AR、VR、自动驾驶，前沿技术层出不穷。不同业务场景与这些技术有机结合，就会衍生出许多新的“花样”。因此，公司产品部门的员工自然是闲不住的，有了新技术，就有机会设计新产品，然后不断地增强自己的竞争力。把握时机，其实就是说企业的数字化转型工作要在正确的时间开展，该做的时候要果断做，不该做的时候也别盲目做。有些行业外在的数字化条件当前还不成熟，比如技术成熟度达不到，市场教育程度不高，没有太多可以参考的成功范例，甚至是行业的准则规范还不健全。如果企业还没有了解自身业务的数字化发展基础，贸然入场，“照猫画虎”，则很可能失败。还有一些企业，虽然已经意识到数字化迫在眉睫，但是可能这些企业的经营漏洞出在业务本身，或者供应链、资金链等环节，那么这些企业首先要考虑的就不是数字化问题，而是要先把原本的业务做好。不管怎么样，企业至少要先做到60分，再考虑变优秀的事。图片来自网络华为，作为一家拥有大型跨国业务的技术企业，在数字化转型方面走在行业前列，并提出了属于自己的数据治理业务标准，成为行业典范。在确立了转型的目标后，我们就要开始真正考虑如何具体执行转型的工作了，而在这个过程中，人又是其中最关键的因素。转型工作需要具体的人员来执行。我们需要专门组建核心队伍来推动转型事业。我们需要寻找能够出色地完成转型工作的人才。这些人才一方面需要对数字化转型项目达成思想上的共识，保证任务协作顺利畅通；另一方面需要具备必要的职业素养，在具体方案落地实施上发挥出足够的专业能力。除了以上方面，人的因素还体现在技术的“以人为本”原则上。数字化转型成果最终会以技术产品的形式落地，比如信息系统，而这些系统最终又会服务于具体的用户。信息系统设计研发的出发点不能单纯地就技术而论技术，而是需要真正地解决业务问题，不仅要好用还要实用，也就是遵循所谓的产品化思维方式来设计和构建。企业领导者下定决心要进行数字化转型时，通常会做一件非常重要的事情，就是在公司层面进行思想宣传，目的是让大家都知道数字化转型这件事。企业“一把手”作为领头人，不仅要自己懂转型的核心思路，还得让企业里的所有人都明白怎么回事，这样才能把自己的想法转化为企业整体的执行力有效落实下去。领导要想宣传一件事，通常采用开会的方式，尤其对于大企业来说，这更为常见。大企业里人员众多，管理层级结构复杂，如果没有把思想传达到位，那么后面在转型实践落地的时候就会遇到很多阻力。公司“一把手”先给管理层开会说明目标，然后管理层给下面的员工开会进行动员，最后达到上下一心。即便是小企业或小团队，也得清晰地把目标通过日常例会、午休聊天、线上会议、公司团建等各种灵活的方式传达到每一个具体的员工身上。数字化转型和员工的工作内容息息相关，哪怕员工不是转型的核心推动者或建设者，也会是转型中和转型后受到各方面影响的利益相关者。企业里所有员工的思想、工作内容、工作方式，包括绩效考核，或多或少地都会发生变化。因此，企业的数字化转型目标需要所有人都认真地了解和学习。数字化转型依赖于深刻的认知，虽然领导层可以达到相当的“认知”水平，但是由于企业员工所处的岗位不同，所在部门的利益角度不同，很难做到思想同步。既然很多事情自己想不明白，就需要不停地交流学习，循序渐进地提高认知水平。在逐级开会传达时，需要注意的是，对于同样的目标，上层和下层沟通时需要学会变通，用能听得懂的语言交流，这就对中层管理者提出了更高的要求。中层管理者不仅要对目标消化、理解到位，还要加入自己的思考，结合所管理团队的具体工作，宣传给大家。其实在不同管理层级的组织宣传中，当沟通语境发生转化时，对应着任务目标的分解：首先上层管理者把企业级宏观、整体的大目标，细分为具体到某个部门、某个团队可执行的小目标；其次在执行环节，通过各个小目标的实现，一层一层地向上支持大目标的完成；最后使每个员工都能明白自己的工作对整个企业这艘大船的航行所具有的意义。如果我们的主管领导只同一线普通员工讨论抽象的名词概念，而不考虑员工的理解能力、思维立场、认知水平和交流语境，则会使大家感到云里雾里，摸不着头脑，结果就是大家听个热闹，事情该怎么做还是怎么做。转型最后也就成了空谈，完全没法落地推动。通过开会宣传的另一个好处在于，能够把数字化转型中可能遇到的问题或引发的冲突都提前抛出来，及时地化解“组织”方面的矛盾，得到大家的一致认同和支持。由于转型可能会给企业带来各种各样的变化，让企业面临很大的不确定性，这就导致企业内部一定会存在很多反对的声音。这些人或许不想适应变化，或许对数字化转型存在误解，或许只是单纯因为和领导的矛盾而不支持，总而言之，心里是存在一些“疙瘩”解不开的。这种情况比“不知道”或“不了解”给转型推动带来的负面影响更大。在转型之前，企业可以通过开会等类似活动，尽可能地消除误解，把转型积极的一面宣传到位，这些都是很有必要的“动作”。总而言之，这种“宣贯会”的目的不是讨论具体的转型方案，或者决定管理方面和技术方面的实施细节，而是统一大家的思想，让大家能够朝着一个方向使劲。当然，开会这种方式还是比较正式的，所用时间也比较短。很多员工对数字化转型的概念缺乏最基本的理解，很难在较短的时间里明白数字化的好处并认可其目标和意义。于是，这就要求企业的管理层提供更多有效的学习机会来帮助员工不断成长，比如可以多分享一些数字化方面的案例和分析报告，或者向与数字化转型密切相关的部门提供一些数字化转型方面的书籍和学习资料。另外，企业还可以主动提供一些内外部培训的机会给大家。例如，可以请一些优秀的数字化项目同行专家给本企业员工介绍转型经验，或者花钱聘请一些外部培训咨询师深入一线团队讲课。不管到什么时候，学习都是非常有意义的事情。数字化转型在实践中很难，对于转型中的企业，员工的素养要快速地提升，要能够跟上转型的整体节奏。不宣传不行，宣传了讲不透也不行，不能嫌麻烦。前面思想工作没做好，后面干活的时候，就会有更大的麻烦，功课早晚是要补回来的。当然，通过宣讲让员工接受数字化转型的理念和目标，只是非常初步的要求。群众基础很重要，改革骨干更是必不可少的。也就是说，除了通过宣传工作让大家齐心协力，更为关键的还是要搭建出真正能让转型执行落地的人才队伍。谈到由企业内部思想和认知不一致带来的转型问题，就不得不提到蒙牛的例子。在近期的一次对蒙牛集团CDO张决女士的专访中，她提到：“数字化转型一定是一个痛苦的过程。思维变了，一切都好变。”开始决定走向数字化转型道路的时候，蒙牛CEO牵头，邀请了各事业部门的一把手参会，共同探讨数字化转型的方针和执行方案。在张决的记忆里，第一次“共创会”的效果并不乐观，各高管的意见不统一，有的甚至觉得转型这件事跟自己毫无关联。这样的工作要怎么推进，对于这样庞大的集团体系来说无疑是一个不小的难题。但蒙牛的高层并未放弃，一次共创会不成功，就开五次，而且每次一开就是两三天，参会人员也从原先十多个部门的一把手变为上百人的骨干员工。最后，共创会从CEO或几个认同理念的核心高管的独角戏，变成了有外部专家参与的头脑风暴大会。历经了多次的争吵、“说服”，再提出异议的过程，共创会慢慢地宣传了新颖的概念。蒙牛转型的首批领导班子就是这样“把认知拉齐了”。而这些，都只是蒙牛最初阶段的基础工作。蒙牛在2020年正式开启“数字化转型”之前，仅筹备工作就花了两年的时间。在这两年时间里，信息化团队从原先的100人扩充至240人，还专门组建了IT和DT两个独立业务部门，进行数字化转型任务和技术环节分拆。这一切都离不开最初提出数字化转型方针的领导，而这样大的决策必然与一把手相关。但单纯的一把手工程也会在向下落地实施中遇到无法预料的阻碍，就像蒙牛最初遇到的情况一样。于是，我们不禁要问：转型班子到底怎么“搭”才能让转型的阵痛期缩短？接下来，我们马上就会讲到这个问题。在确立目标之后，转型这件事的具体落地就要开始做了，这时候需要进行人力组织方面的安排。对于大型企业来说，需要严肃认真地搭班子，构建转型专项工作团队，形成比较正式的工作小组，但更多的时候，很多企业只需要形成一种跨团队工作的协作机制。数字化转型需要专门的特殊人才，需要很多既精通技术又精通业务的综合背景专家。从工作定位来划分，数字化转型所需要的人才分为高级人才、中级人才和一般人才3类。高级人才是对数字化相关信息技术“精神内核”理解透彻的人，他们对技术如何影响业务，以及业务在技术大环境下的发展方向能够精准判断并把握。高级人才可以是牵头数字化转型项目的CEO（首席执行官）、COO（首席运营官），或者CTO（首席技术官），也就是公司中“说话算数”的高层领导。当然，他们也可以是在某些前沿技术驱动的转型中，对某些高精尖技术研发工作能够起到重要指导作用，或者有能力推动重大技术创新的科研人才。高级人才负责目标和方向，决定数字化转型的顶层设计。需要注意的是，高级人才其实并不需要了解技术细节，他们将更多的精力放在对业务本身的统筹和规划上。在这里，对高级人才的能力要求是认知大于技术。同时，高级人才需要有对业务数字化转型可行性进行准确判断的能力，比如在转型早期，能够考虑清楚什么样的业务适合作为转型的试点，优先“发力”，起到示范作用。这种事，恐怕只有在业务领域深耕多年的“老干部”才能深刻领悟。中级人才，通常也是转型工作的中层领导，如部门经理，他们对数字化转型的认识也同样需要非常深刻，中级人才的多少决定了数字化转型结果的有效程度。中级人才要负责转型设计规划和具体执行落地之间的工作内容转换，也就是从数字化转型的抽象目标到具体任务的分解。此外，他们要负责人员之间的沟通协调，提供数字化转型的具体解决方案，解决资源问题和人力调度问题，甚至会承担起某个具体信息系统的设计和建设工作，或者配套管理制度的设计工作。一般人才覆盖了所有和数字化转型任务相关的一线基层员工，他们负责数字化转型的具体执行部分。企业在数字化转型中，对一般人才的需求量是最大的，一般人才的平均职业素质、人数，决定了数字化转型的总体推进效率，也决定了转型工作对企业经营状况的影响力度。数字化转型的一般人才包括信息系统的开发、运维人员及数据管理人员，也包括配合梳理业务，对业务进行分析建模和流程设计的业务人员。数字化转型的一般人才广泛分布在企业的各个团队和部门中。如果企业自身的人才基础比较过硬，那么自己就可以独立开展数字化转型工作；如果企业的人才基础比较一般，那么就得依靠外部合作来推动转型。但是，无论是“找外援”还是自己做，数字化转型这件事绝对不是纯粹的“外包”工程，决心要做数字化转型的企业，还是要培养自己的人才的，并逐步接手数字化项目中的系统和业务优化工作。转型不是一朝一夕可以完成的，转型是“以终为始”的、持续的，企业迟早需要自己“学会”数字化的全部核心工作。总之，可以认为数字化不是一个简单的“项目式”任务，而是一种全新的、常态化的企业运行状态。一旦企业进行数字化转型，就“开弓没有回头箭”，企业的员工就要真正具备足够强的综合能力把这件事承担起来。例如，中国石油塔里木油田公司（简称为“塔里木油田公司”）作为中国石油天然气集团有限公司数字化转型的首批重点示范单位，将“大力推动数字化转型”这一目标，写到了企业“十四五”规划当中，并独立组建自上而下的完备团队，通过推动顶层管理人员和运营模式的全方位规划，制订了详细的五年计划，全力推进企业的业务数字化。塔里木油田公司组建于1989年，截至目前，整个企业人员规模约1万人。在这样大而完整的体系当中，各环节设备创新对于资产总值为几百亿元的企业来说并不是难事，但运营体系及经营理念的数字化转型并不是那么容易的。2021年8月，中国石油天然气集团有限公司正式启动“数字化转型智能化发展”试点建设，仅集团总部为建立信息化管理组织、制度和流程，就专门设立了规模达1.6万人的信息化建设与应用专业团队。彼时，塔里木油田公司也同步成立了包括决策层、管理层、执行层、协作层在内的“四级”完备组织体系。决策层，相当于上面提到的高级人才，懂得如何响应集团总部的整体数字化转型目标，规划塔里木油田公司的短、中、长期数字化转型的“里程碑”节点，并对实现这一目标的基本方针给出方向性的指导。管理层，就是上面提到的部门经理级别的中级人才。这个层面的人才对技术有相当程度的理解，能够确定技术层面顶层设计思路和框架。同时，管理层需要对所管理人员的长项和整体工作时间有非常明确的概念，能够通过沟通与协调，推动科研人才、技术人才、业务人才齐心协力地实现企业的宏观转型战略构想。执行层，就是我们上面提到的一般人才了。当然，一般人才也必须是人才，要有一技之长，并且能够独当一面。例如，软件工程师、精算师，以及在专业岗位上工作多年，熟悉各个设备运作方式及故障多发诱因的业务专家，他们或多或少地承担着企业转型中的重要责任。协作层，从某种程度上不算专门为数字化转型设立的独立层级，它是在一项创新方略转型过程中，各部门之间协调的“润滑剂”。例如，塔里木油田公司数字化转型班底中的相关二级单位负责人，这些人所负责的大部分工作可能还是原先的本职工作，但他们的存在决定了集团整体推动数字化转型的实际效率和效果。综上，塔里木油田公司成立了由执行董事、党工委书记任组长，领导班子成员、信息与自动化首席技术专家任副组长，首席技术专家、总经理助理、副总工程师、机关部门和相关二级单位负责人为成员的数字化转型智能化发展工作领导小组的全方位班底，推进从集团到塔里木油田公司各层级数字化转型智能化发展工作的“十四五”规划目标的实现。这套班底密切协作，成果卓著，开发了塔里木油田勘探事业部远程管控支持系统、“天眼”+预警的VR监督设备、非常规作业移动式实时视频监控装置和智能工程录井预警系统等各业务阶段智能化方案的软+硬件智能化设备及系统，并将一系列数字化系统试点成功后复制到超过20个勘探基层站队。在转型期间，团队完成了远程处理复杂井、远程巡检、自动报警等任务，单通过视频回放发现的隐患就有55项，智能工程录井预警系统的应用覆盖面可达到100%，异常预报共计1116次，及时率为100%，准确率为92.8%，基本实现了油田工业化场景的数字化转型目标。类似这样能够在工业化场景中提升工作效率，降低人员成本，甚至直接减少现场事故率并提升现场作业人员安全程度的案例还很多。不过，像中国石油天然气集团有限公司和旗下塔里木油田公司这样，能够在如此短的时间内搭建如此完备业务班底的企业确实并不多见，其转型的实践方法和经验，确实值得多方探讨学习和深入研究。数字化的目的是什么？无非就是解决最终的业务需求。数字化的创新模式需要用到数据分析技术，所以很多企业在进行数字化转型的过程中，会过度地强调数字化的技术过程，而忽略了数字化的业务目标。这种思维误区产生的工作方式偏差，最终导致从数据中凝练出来的创新思路仅仅停留在一个“有意思”的概念上，而无法实现有效的业务落地。那么问题出在哪里呢？其实就是缺乏一个有效的产品化思维。数字化转型往往是要有应用系统产出的，也就是构建一个技术产品给业务相关的人用，如果想把数字化技术引进来，就要保证“有人愿意用”这个技术服务。成功的数字化转型成果不是一个简单的系统，也不是业务逻辑的变化，而是系统加业务的组合模式。所以说，单有系统不行，还得有人用系统实实在在地解决问题，能够把系统用得好。而解决“系统使用”问题的关键，就是要在系统的设计阶段具备产品化思维。产品化思维是做技术产品的基本思维模式，说白了就是要换位思考，多替使用者考虑，把技术系统带入具体的应用场景里来充分设计。这是一种重要的“同理心”。如果不具备产品化思维，就很难创造出公认优秀的技术应用。从数据中发现业务机会到成功应用，中间其实还隔着很远的距离。盯着一个Excel表看，瞬间会产生很多有趣的想法。这个不难，难的是将这些想法落实到实践过程中的一系列艰苦探索：从数据中发现业务机会；设计技术方案计划；将技术方案计划落地实施；价值发现；价值应用；产生应用效果。Davis等人在1989年研究出来的技术接受模型或许可以给我们一些启发。这个模型提到，用户是否会使用一个新的数字化产品，取决于他的主观意愿是不是积极的。这个主观意愿背后又会受到两个因素的影响：一是感知有用性，就是这个产品能不能解决实际问题；二是感知易用性，就是这个产品好不好用。图片来自网络感知有用性和感知易用性都高的技术产品，基本上就算成功的技术产品了，比如微信、抖音、拼多多。先不管这些产品在市场推广上投入了多少成本和精力，单从产品设计方面看，确实做到了满足咱们老百姓日常生活中的实际需求，并且老少皆宜。咱们先来介绍一下感知有用性。其实一个技术产品有没有用是因人而异的，软件开发工程师觉得有用的东西，产品经理未必觉得有用，而产品经理觉得有用的东西，用户未必觉得有用。每经过一层角色的转换，产品需求都会“变味道”。数字化创新不能闭门造车，然而要想做到站在用户角度去思考问题，其实也是很难的，这也是很多数据应用项目最终失败的原因。如果想要了解用户的需求，则最直接的方式就是进行用户沟通，然而在现实情况中，用户并不会把真实的想法表露出来，他们只有一个模糊的目标，不会清晰地告诉你想要什么。我们设计技术应用的时候，有时候会“抱怨”用户为什么总是对着干，不好好提需求，然而事实是用户根本就提不出需求。让用户提需求，这个要求太高了，要知道这并不是用户的“义务”，用户只想解决他们在生活中或工作中遇到的问题，至于解决问题的方法和数字化有没有关系，对用户来说并不重要。那么这种情况下究竟该怎么办呢？我们需要做的，就是场景模拟。把我们自己想象成要服务的用户，模拟他们的业务活动。我们需要研究，在现实的业务场景中，到底包含了多少个业务活动环节，每个环节用户都做了哪些事，其中哪个环节是让人“头疼”的，这个环节是否可以被机器活动替代，等等。从有用性的角度出发去设计数字化的产品或服务还有一个好处，就是可以有效地避免陷入“技术陷阱”。“技术陷阱”是企业在进行数字化转型时非常容易踩到的“坑”，即一味地追求高科技，寻求炫酷的算法或新颖的数据分析思路，忽略了算法本身是否能够有效解决业务的实质问题。这种情况尤其容易出现在由技术“牛人”牵头的数字化项目中。很多时候，数据不是万能的，算法也不是万能的，衡量一个数字化应用是不是“高级”的标准不应该以技术的复杂性来判断，而是应该考虑技术到底能不能解决实际应用问题。技术有技术的优势，人有人的优势，人和机器只有协作互补，才能发挥出更大的智力潜能。具体来说，机器比较适合处理大规模的数据存储和数据计算问题，但是机器处理的问题受限于问题的标准化程度；人虽然能够处理相对抽象、综合的问题，但是对数字的处理即不够敏感，也不够快捷。很多需要数据分析支撑的业务，机器或许可以帮上忙，但是如果只依赖于机器，则在当前的技术发展情况下，无论多么复杂的算法都很难达到人的水平。我们与其在算法上没完没了地较真，投入大量的研发成本来训练机器达到人类专家的水平，不如让人和机器一起干活，让机器做人的助手。例如，现在有很多算法模型可以自动地从文档中“抽取”关键的业务信息，并将其提供给相关领域的专家进行决策分析。这类技术在财务报告数据分析、医疗保险材料分析、书面试卷自动审核等方面具有很大的应用潜力。让算法在这些任务上达到人的“认知水平”是很难的。于是，在行业应用中，一般采用退而求其次的方法，也就是让机器根据一些人为定义的分析模板自动处理文本内容，再让人快速地把处理过的信息进一步审核或补充。这里，机器以一种预处理的方式参与到了信息的抽取活动中。那么，感知易用性又该怎么实现呢？用户需要尽可能简单、便捷地使用数字化产品，不需要进行太多的操作。更多的时候，“操作”其实应该是无感的。例如，很多电商平台都是通过自动推荐的方式，让信息和服务主动触达最终的用户，而不是让用户自己去搜索想要的内容。虽然现在的人已经慢慢适应了信息技术的快速发展，计算机、手机、iPad等电子产品使用得越来越顺手，但是人们的性格总归是比较“懒”的，一个技术产品被设计得越复杂，越多的潜在使用者就会被“丢掉”。感知易用性除体现在操作的便捷方面外，其实还有一个非常容易忽略的“点”，就是结果的可理解性。当数据进行漫长的加工处理，最终带着有价值的信息以可视化的方式呈现给用户时，应当是容易理解的。用户需要什么，系统就应该反馈什么，而不需要把多余的内容都“倾倒”给用户。如果用户想要得到系统推荐的产品，那么就应该把产品列表图文并茂地展示出来，至于复杂“算法”为每个产品计算出的相关性量化指标，则不需要特意呈现。类似地，如果用户想知道工厂园区哪里突然发生了异常情况，那么就直接在地图大屏上把这个地方“高亮”显示出来，这个时候图形会比具体的数值更能直观、有效地传达关键信息。产品经理是软件开发项目中非常重要的角色，承担了一个技术项目从业务需求到开发需求之间的重要衔接工作。在一个行业中，优秀的产品经理非常稀缺，既要非常懂底层业务的逻辑，也要具备与技术人员和谐沟通的应变能力。对于企业来说，确定了需求和目标，配齐了核心的转型人才团队，接下来就要确定具体的转型方案了。在操作层面，由于每个企业的具体经营费“处境”不一样，所以数字化转型工作并没有统一的方法可以“抄作业”。尽管如此，我们还是尽可能地总结出了一些规律，对全行业企业进行一个基本分类，然后为每类企业在“总体”的层面上提供一些“相对通用”的转型思路。首先，我们把企业分为传统企业和技术创新企业。这里传统企业和技术创新企业与企业所在行业的科技属性有一定关系，但更多是按照企业是否较多地引入信息系统来支撑自身核心业务来划分。其次，我们还可以把企业分为小微企业和大中型企业。大中型企业的数字化转型比较复杂，难度也比较大，但是小微企业的转型需求也不容忽视，毕竟从整个市场的规模来看，小微企业所占份额仍然是主体，各行各业的市场活力和创新能力在很大程度上都依赖小微企业的重要贡献。最后，我们分别为大中型创新企业、大中型传统企业、小微创新企业、小微传统企业提供一些可行的转型建议。大中型创新企业：推进系统整合，有规有矩才持久大中型创新企业的数字化基础较好，很多核心业务的开展已经率先实现了信息化和自动化，并在已有的业务中持续积累了大量有价值的历史数据。尽管如此，这些企业的业务系统在管理方面十分混乱。在早期的业务快速扩张时期，为了应对不同的业务场景，覆盖到更多的用户，并占据更多的有利市场，企业构建了各种各样的信息系统。这些企业内部信息系统之间的结构关系错综复杂，由于各业务的上线时间都很紧，几乎每个系统都是“赶时间”做出来的。这些系统的建设遵循着不同的软件开发标准，使用了不同的程序开发语言，被不同的技术团队“负责”开发，并且被不同的业务部门、团队，或者分公司进行管理和运营。在这种情况下，这些业务系统产生的数据几乎很难实现互联互通。每个系统都按照自己的流程在“跑业务”，遵循自己的独特场景和方法逻辑在使用数据、生产数据，于是每个业务系统中的数据，都留存在自己的“孤岛”上。这些数据的存储位置不仅在物理上分离，甚至连存储的格式也大不相同。这就意味着，对于企业来说，同时存在着多套平行的“数据应用体系”，没法把来自不同系统的数据用“同一个故事”串联起来。除此以外，这些企业不仅业务系统建设得没有条理，而且在数据管理方面也存在着诸多棘手的问题。例如，不清楚数据在哪里，不清楚是什么意思，不清楚怎么用，最后导致基于数据的业务创新变得非常困难。对于大中型创新企业，数字化转型的根本目的，是进一步提升自己的数据管理能力和数据应用能力，进一步加强数字化业务的拓展能力、运营能力和创新能力。这些企业在数字化转型中最紧要的事情就是整合已有的存量业务系统，规范系统的管理，统一数据存储的标准，建立数据使用的规范。实质上，数字化转型就是对数据及产生数据的信息系统进行整顿，为数据的使用、数字化业务的创新，提供良好的发育土壤。对于大中型创新企业来说，最常用的做法是开展规范化、平台化的信息系统建设工作，通过建设一个统一的“大系统”把之前杂乱不堪的“小系统”都囊括进来，对这些“小系统”的核心功能和服务进行集中化的接入和管理。在实际操作层面，这个“大系统”有很多具体的形态，其中比较主流的就是我们在数字化转型中常提到的“中台”。中台是什么及中台怎么建设是数字化转型中非常重要的“课题”，以至于很多人把中台建设理解为数字化转型。顺便一提，关于中台现在有很多误解。有的人说中台不管用，也有的人说中台建设的效果不如预期，还有的人说中台不靠谱。这里需要澄清的是，并不是所有企业的数字化转型都需要建设中台，也不表示建设中台就要建设成体系化的中台系统。有时候，我们需要的只是中台的思想，即对系统、数据进行集中整合与管理的思想。因此，这个大系统的建设一定是要经过统筹规划的，是经过规范化设计的，不是为了应对某个突然的临时业务上线，也不是为了从某个业务中获取直接的经济收益，而是出自管理方面的目的。这个大系统的建设是个大工程，需要投入很多精力、财力和人力。在建设这个大系统之后，企业的很多技术研发工作、系统上线工作、业务管理工作，都会面临很多方面的调整。于是，企业就可以从一个综合系统的建设项目“切入”进行数字化改良，以点带面，然后对企业整体的数字化创新能力进行完整的升级重塑。当前，很多关于数字化转型的培训类课程及数字化转型的科普图书，都是面向这类企业提出解决方案的。这种企业的数字化转型，由于技术底子好，所以更多的工作在于如何进行系统架构和数据架构的重新设计，数字化转型的重心在于“体系优化”。另外，对于大型综合系统的建设，在资金投入上确实也要花不少钱，动辄千万，为了企业综合能力的升级改造，或许只有大中型创新企业才有这种决策和执行的魄力。大中型传统企业：接受全面改造，勇敢走出舒适区对于大中型传统企业，数字化转型的复杂度和难度都非常大。这些企业的规模很大，“财力”也较强，但是行业经营模式非常的传统，很多企业的业务开展，包括内部的运营，都逐渐变得效率低下。由于外部市场环境“激烈变动”，企业可能会面临着不可知的市场危机，整个社会的信息化和智能化进程飞快，新兴的技术很可能会带来更多的潜在竞争者。传统大企业的“龙头”地位似乎变得岌岌可危，稍有不慎，就可能被新的行业“进入者”颠覆。而这个颠覆者，都不一定是本行业的可见竞争者，很可能来自一个全新的产业模式。因此，当前已经有越来越多的大中型传统企业充分地意识到数字化转型的必要性，并且开始准备给自己“动动筋骨”，进行产业升级。“居安思危”是必要的，新技术的出现会给各行各业都带来机会和挑战，不仅是先天就具备技术基因的行业，也包括一些看似非常传统的行业。这些行业的大企业靠着传统的经营模式或许已经“称霸”市场几十年，甚至超过一个世纪，但是一旦停止了学习和进步，就有可能随时被“击倒”。传统大中型企业的数字化转型有很多“老大难”的问题，虽然这些企业愿意花钱，肯下本，但是更多的问题无法靠金钱解决！首先，很多传统行业的企业根本就不知道怎么进行数字化转型，对本传统行业的数字化形态缺乏足够的想象力，找不到数字化转型的方向和目标。很多传统行业，无论是国内的还是国外的，都没有什么可以参考的先行者，数字化转型工作属于摸着石头过河。这种情况，就更容易让企业员工从上到下，都更加愿意待在舒适区里继续“混日子”。改变吧，怕担风险，不改变吧，似乎又没什么事情可做，就只能循规蹈矩。但是这种所谓的“舒服”似乎又让人感到很不踏实，尤其是对于那些“看得更远”的领导者。同时，这些企业的数据管理基础特别差。传统的大中型企业，可能自身的信息化水平原本就不高，很多信息系统的使用只是为了支撑企业内部的基本管理，提高办公效率，而对于业务的开展，也只是局部环节采用了一些电子化的设备。大多数的业务并没有产生“高质量”的数据记录，然后很多数据的录入和分发工作，都是靠人工的方式进行下载和整理的，并没有采用自动化方式进行信息的管理和推送。在业务的开展过程中，重要的数据信息可能只是简单地依靠人力用Excel表格进行“傻瓜式”录入，然后按照文件夹分门别类地存放，数据是什么意思也只能靠文件名来区分，而对于数据的传播和使用，很可能就依靠U盘从一台计算机转移到另一台计算机。这不是讲故事，很多非常“古老”的企业还停留在这个水平的数字化阶段：核心数据没有完成成熟的线上化，数据也是乱存乱用，不仅效率低下，而且在数据安全方面也存在着很多隐患。这些企业在进行数字化转型时，可能并不“着急”进行数字化业务创新，毕竟思路和方向暂时也不明确，需要探索。但是不管怎样，传统大中型企业都需要先做一些事情来补足短板。例如，加强对现业务的线上化升级，让更多的业务能够通过线上系统留下数据痕迹。在这个过程中，可能要新建设一些业务系统，同时，对原有的落后业务系统进行升级改造，提高这些业务系统的服务能力。业务的线上化升级其实就是所谓的“信息化”。信息化是和数字化比较接近的概念，在过去的二三十年里，很多企业都通过信息化“吃”到了一波技术红利。信息化意味着企业更多的业务过程实现自动化的可能，可以提高效率，本身对企业的产品和服务质量的提升是有很多好处的。但更重要的是，信息化解决了数据来源的问题。毕竟，数字化转型离不开数据。如果一个传统企业在信息化方面，系统建设工作做得少，那么当到了数字化转型的时候，就得“补课”，否则转型起来就很吃力。当然，系统少的话也有一些“意外”好处，就是可以在系统最开始建设时加以统筹考虑，进行一些成体系的建设规划，避免前面提到的很多大中型创新企业所面临的系统建设“杂乱无章”问题的出现。对于大中型传统企业，需要对数据集中管理并制定科学严谨的数据使用规范。尽管这些企业中能够批量自动地生产出标准业务数据的信息系统不多，但并不意味着没有相应的业务数据。这些数据散落在企业各处：可能在某个人的计算机桌面上，可能遗忘在某个U盘里，可能在某个小团队内部共享的网盘中，也可能在几个业务骨干微信群的聊天记录中……而更多的情况是，很多有助于业务创新的核心数据根本就没有以电子化的形式进行存储。在数据方面解决企业问题，关键就是要清楚这些数据在哪里，然后对它们进行统一的组织存储和应用。国家电网有限公司（简称国家电网），作为一个传统国企，在数据管理和数字化战略上制定了明确的目标及规范。为顺应2020年8月发布的《关于加快推进国有企业数字化转型工作的通知》的要求，国家电网对内发布了“夯实数字化发展基础，坚持不懈狠抓管理”的具体要求。图片来自网络具体到执行层，国家电网建立了跨部门、跨专业、跨领域的一体化数据资源体系，并提出了面向“盘点—规范—治理—应用”4个环节的一整套数据资产管理自我完善的管理理念，建立了最小化的数据共享负面清单，尽可能地在各业务、各部门间进行顺畅、高效的数据复用与分享，减少“部门墙”造成的壁垒。此外，国家电网在北京、上海、陕西3个地区建立了自己的数据中心，要求强化“两级部署、多级应用”，制定了加快27省市数据中心的升级改造目标和实现核心业务数据统一服务体系的1.9万台服务器的采购目标，总数据存储量高达30PB，堪称传统国企数字化转型的表率。除了上面提到的两方面，对业务进行数字化建模也是非常值得关注的转型基础性工作。例如，传统企业可以为数据添加业务标签，构建关于业务的知识体系，完善业务的统计指标。知识体系包含了一切关于业务的数字化知识。业务知识是支撑一家企业不可替代的业务能力，对业务知识的管理是企业创新增长的核心。对于很多传统企业来说，业务知识大多存储在业务专家自己的头脑里，只能口口言传，无法批量复制和应用。这种情况很容易造成一个企业内部的“知识垄断”，导致新人成长慢，老人“倚老卖老”，而企业整体效率低下。此外，不同部门之间也会难以合作交流，缺乏统一的业务语言。因此，要想实现业务的数字化，就得先完成业务知识的数字化，也就是把核心的业务知识搭建成计算机可以理解的知识体系，用特定格式进行统一的存储和管理。这些重要的知识体系可以帮助我们查询数据、解读数据、分析数据、使用数据，是一切业务线上化和智能化的基础。可以说，任何数字化业务的创新，底层都依赖于知识体系的构建。那么知识体系到底是什么呢？简单地说，就是把业务活动从线下转到线上的信息模板。有了这个模板，就有了对数据进行计算和分析的基础。知识体系的建设是一个浩大的系统性工程，解决的是知识如何表达的问题，依赖于强大的业务理解和数学建模能力。一个传统企业，如果要构建起自己领域的知识体系，就需要在技术和业务方面都有足够专业的综合人才。大中型传统企业的数字化转型难度大，可以参考的案例不多，数字化创新的方向不明确，现成的成熟方法少，企业要做的技术基础准备也特别多。与此同时，由于企业长期按照传统模式运营，工作方式也传统，企业内部的数字化人才也比较缺乏，核心领导层和管理层在数字化方面的思维方式上也存在很大的“认知”上的局限。因此，大中型传统企业的数字化转型，大概率是要找外援的，如果非要自己独立开展转型工作，就需要对组织结构进行非常大的调整，大量引入相关人才。这样，对原有的管理层人才结构可能会造成很大的冲击。这就又牵扯到另外一个问题了，那就是人的利益因素。不管是否在管理层“空降”数字化人才，数字化都会打破传统企业现有的利益格局。毕竟，传统企业的管理层大多是业务背景出身的，整体数字化技术水平并不高。数字化转型对管理层人员提出了更高的要求，也会影响到管理层的价值，二次创业总是让人焦虑的。怎么解决人的问题，创造一个让大家齐心协力的良性企业文化，是传统企业面对数字化转型的“根子”问题。只有先把这个问题梳理清楚，再进行技术的布局和探索，才能保证转型落地有所支撑。小微创新企业：聚焦业务创新，尽快形成数据闭环对于小微创新企业，在数字化转型中，对系统和数据的整合与管理其实不是最迫切的事情。这些企业一般都已建成了一些成形的业务系统，但是与大企业的不同之处在于，这些业务系统通常比较垂直、单一，业务逻辑比较清晰。小微创新企业在系统和数据管理方面，由于规模和复杂性的原因，暂时还没遇到瓶颈。这些企业，主要面临的还是“生存”问题，没有找到持续、稳定的盈利“曲线”。数字化转型对于这些企业的价值，本质上在于提供更多的发展机会，成为这些企业获得竞争力的有效手段。小微创新企业因为业务本身已经实现了线上化，或者本身就是在从事互联网相关的行业，因此可能已经积累了一定规模的、有价值的业务数据。对于这些企业来说，当务之急就是把这些有价值的数据积累起来，通过精准的业务模式设计，“跑通”从数据到业务再到数据的良性数据闭环，从而迅速完成从小型企业到大型企业的身份转变。小微创新企业需要提高对数据的理解能力和应用能力，不断进行数字化业务创新，对于它们来说，数字化就是要开拓出更有价值的“智能服务”。小微创新企业需要加强对自身行业的学习，提高对业务的理解，并且提高对业务产生数据的理解，然后充分挖掘数据背后的潜力，实现数据核心价值的最大化。在深入梳理业务逻辑的基础上，需要加强对数据的分析和整理，结合现实的业务需求，设计“巧妙”的数据服务模型，完成业务的升级改造。除此以外，这些企业也可能面临着业务发展方向的转型，数据积累可能只是他们第一阶段的产物，并不会产生持久、可观的收益回报。但是，通过对第一阶段积累的数据进行分析，可以挖掘用户需求，了解用户的行为特征，并基于此开拓、聚焦真正有特色的业务，实现业务的升级。例如，某互联网创业公司，构建了一个基于旅游社交的垂直领域App，用户在App的地图上可以进行景点的“打卡”，上传旅游照片，分享自己的旅游经历。用户可以彼此互相关注，了解所关注的好友去了哪里游玩，吃了什么美食，采用了什么交通方式，以及了解当地的旅游特色。通过运营这样一个趣味App，该公司积累了大量对旅游感兴趣的粉丝群体。通过对这些旅游爱好者的关注行为、浏览行为，以及发布“打卡”照片的分享行为进行数据分析，可以精准地挖掘他们的潜在旅游需求。该公司可和提供旅游产品及旅游服务的企业进行合作，帮助它们进行广告宣传和业务引流。例如，该公司通过大数据分析发现某个用户经常浏览大理洱海“打卡”的记录，并对旅游照片进行频繁点赞和收藏操作，于是预测该用户对云南区域特色旅游项目具有较大的兴趣，并可能愿意付费参加类似的旅游项目。通过App，该公司自动地把云南旅游项目的产品链接和对应的折扣信息推送给该用户。除了以上方面，小微创新企业，为了增强自身的数字化基因，也可以把重点放在创新技术的引入和研发方面，以此挖掘自身的核心技术潜力。总之，小企业的数字化转型痛点不在于管理，而在于业务创新，其本身的财力资源也有限，应该把钱花在刀刃上。对这些企业来说，不管是在业务逻辑上，还是在信息化、智能化技术上，都应该聚焦前端的特色业务场景，集中精力和财力对核心业务重点进行突破，等公司的体量规模上来了，再考虑“大而全”的数字化体系布局。小微传统企业：充分借助外力，少花钱也能办大事对于小微传统企业，数字化转型的逻辑相对简单，但是小微传统企业在国内整体大的行业分布里占比很高，因此数字化转型的市场潜力也比较大。小微传统企业由于体量规模比较小，业务线相对简单，所以在数字化转型时，在技术上不会遇到太高门槛。这些企业转型的关键和小微创新企业一样，需要找到合适的转型方向和定位，才能更好地发挥自己的核心业务优势。小微传统企业的业务逻辑比较常规，商业模式的个性化特征不明显，在进行数字化业务设计时，通常会采用比较通用的技术模块。因此，对于很多小型传统企业来说，一般仅依靠现有的商业软件套件或商业平台，就可以实现自身业务的数字化转型，没必要花钱、花精力去探索高深的技术问题。小微传统企业的业务甚至可以采用“半自动化”的形式开展，仅在部分环节采用数字化的解决方案。当业务体量不大的时候，传统业务中的人力操作部分可以在一段时间内保留，逐步推进，这样也降低了员工接受数字化技术的门槛。在数字化转型中，要充分地考虑到小微传统企业员工在IT方面基础薄弱的问题。也正是基于这方面的考虑，在选取技术方案的时候，可以尽量选择比较容易上手的软件工具，其实有时候，小工具也可以解决大问题。数字化不等于复杂的信息系统建设，数字化是一种思想，只要用好数据把业务做好了，就能算好的转型案例。例如，我们可以使用企业微信对用户群体进行集中管理，在企业微信中把用户按照业务标签分类，批量操作，定向推送营销信息，企业微信就直接充当了一个微型的客户关系管理系统。具体来看，对于某个服务行业的小店，比如美甲店、买手店，或者美容院，可以把用户按照消费能力的高、中、低进行分组，并对用户打上“上班族”“家庭主妇”“学生党”“羊毛党”“爱宠一族”等典型的业务特征标签。当这个店铺推出适合某一消费群体的服务或产品的时候，就可以通过业务标签筛选出满足条件的人群，然后针对这个特定群组，批量发送编辑好的广告链接或购物链接。更进一步的应用，就是充分挖掘消费支付的线上化潜力。今天，不管是传统行业还是新兴行业，只要直接面向C端消费窗口，哪怕只是胡同口的一家早点铺子，就会提供微信或支付宝的收款二维码。这就相当于通过接入第三方平台，快速实现了业务环节的线上化。这一点，基本上在全国的商家范围内都完成了普及。但是这仅仅是在线支付，还不算数字化应用，真正的数字化是充分利用商户端的消费记录数据，对用户的行为特征进行分析，自动地挖掘用户需求。然后，在恰当的时间提供恰当的产品，以促成更多高利润的交易。很多商户为了更好地管理消费者，都会开发自己的App或小程序作为直接面向用户的消费入口，然后把这些消费入口按照统一的开发标准，对接到微信或支付宝的第三方支付平台上。对于C端的这类消费应用，不同类型商户的需求都差不多，只有界面上有很小的个性化差异。除此以外，基本操作流程都是扫码、选择门店位置、选择商品、放入购物车、下单、支付。如果有额外功能的话，则可能是选择消费卡包，设置“自提”或“配送”，或者填写收货地址。因此，这类应用的开发，本身难度并不大，成本也不会太高，有时甚至可以直接“采购”一个现成的软件，或者基于软件模板进行非常快速的迭代生成。小微传统企业的数字化发展，很多时候会被整合到大企业的数字化计划中。就像前面提到的那样，随着数字化转型工作的深入，大企业通常会建立起统一的大平台，这个大平台整合了海量的数据并提供丰富的数据服务。这些数据服务不仅能给企业内部的部门和团队使用，还可以对外进行赋能。也就是说，大企业通过足够规模的数据资源，对其所在行业生态中的小企业进行数字化的服务输出。打个比方，大企业就像是航空母舰，而这些数字化转型中的小企业就是停靠在航空母舰上的飞机，技术变革推动它们一起“超越”。因此，有意愿强化自己能力的传统行业小企业，就应该主动寻求与大企业在数据方面的合作，充分整合与自身业务发展相关的行业数据资源。袁文泽博客http://www.yuanwze.cn这个大企业可以是所在行业中的，也可以是其他行业中的，关键在于这个大企业平台的数据能力与当前正在准备转型的小企业的数字化目标是否相关。通过整合有价值和高质量的数据资源，可以帮助小企业发现更多的业务机会，让小企业根据自己的业务痛点设计出更多“有趣”的数字化应用模式。近期，已经有不少小企业开始着手加入数字化转型的行列中。北京一家名叫“高清口腔”的传统老派诊所，在中关村方圆不超过20公里的地方曾经开过3家连锁店。这家诊所几十年如一日服务于方圆三五公里的老旧社区居民。这些老顾客大多是与诊所建立了20余年交情的附近居民，有的甚至三代同堂。然而，这家看似稳定的社区诊所，在市场的大的变革背景下，也开始遇到各种危机。常年来，由于老顾客搬家或工作单位变化，诊所的业务量不断下降。同时，发展空间受到其他新开诊所的挤压，在行业竞争方面也遇到诸多挑战。究其原因，主要是对老客户的跟踪服务不及时，新客户开发无门。此外，同行诊所不断推出新奇的营销手段，也让这些专注于医疗技术与具有传统服务态度的“老大夫”多少有些力不从心。近期，受到“老大夫”儿女们的影响，高清口腔开始下决心接受信息技术的改造，先从信息化开始，逐步完成数字化转型的业务升级。图片来自网络首先，其将原先积累了20年的上万份病历，通过“牙医管家”SaaS软件，实现了就诊记录的电子化，提高了病历搜索的效率和准确性。然后，医生们在软件当中对重点病例进行复盘和比较，挖掘患者的性格特征，对“老朋友们”进行标签分组，以精准医疗为目标，提供个性化的治疗方案和口腔预防与护理的建议。在线下的门店就诊服务方面，通过企业微信群管理，实现患者就诊预约的柔性时间安排，针对患者的口腔健康需求偏好，安排合理的保健套餐，并设置定时、定项的消息提醒等。除此以外，为了提升用户黏性，增强病人的护牙意识，促进医患之间的沟通效率，高清口腔还通过微信公众号平台不断向患者定向推送护牙小文章，普及口腔知识，增强患者的信任感。对于餐饮这种传统的服务行业，可以通过模板快速开发出自己的小程序，提高业务效率；每家店都可以快速搭建属于自己的“大众点评”；送餐机器人的广泛使用，也大大节约了用工成本，同时也有效提升了菜品送到餐桌的效率。}

文
张丞
编辑
石亚琼
封面来源｜IC photo
前言
本文是智能制造系列研究的第三篇，前面《智能制造走向深水区》提出装备和工艺智能化和仿真促进正向设计是智能制造发展的两个重点，《锂电装备二十年进化史》以锂电产业中锂电设备的行业发展为例，梳理总结了装备制造业自身的发展规律以及对下游行业的支撑作用。本文我们仍将以锂电池行业为例，阐述仿真技术在锂电池行业的发展现状和发展趋势、仿真将如何促进正向设计等方面，并希望和读者朋友们探讨国内锂电池CAE软件未来发展的突破口。
当企业进行原创性的研发设计时，特别是整个产品体系需要从头创新或有很大变革时，就需要根据需求目标进行正向产品设计，通常会需要耗费大量的物料和人力进行制样测试，仿真的意义和作用就在于帮助企业尽可能减少制样测试的次数，避免盲目试错，获得更优的设计方案。仿真软件的发展是以人为核心，围绕着帮助仿真工程师以及非专业相关人员更好、更快地正向设计出最佳的产品工艺方案这个核心。
工业仿真软件的涌现依赖于制造业的发展，一个新兴制造业的发展必将带动相关设计仿真技术的进步，从而孕育出新兴工业软件，而设计仿真的进步又将反过来推进行业整体的发展。目前锂电池发展已经出现了多条技术路线，对能量密度、功率密度、寿命及安全性的要求越来越高，而耗时长、成本高的实验试错研发方法越来越难以适应下游市场的需求，因此需要在设计仿真方面实现较大的突破。同时，我们注意到电化学理论仍在不断发展，一些相对新兴的数值模拟算法也逐渐应用到锂电池仿真领域，这些条件为国内锂电池CAE仿真软件的发展提供了较为有利的条件。
下文中我们将先从锂电池仿真技术现状和前沿发展趋势展开，接着分析开发CAE软件所需具备的功能特点以及CAE软件当前的发展趋势，并结合以上两方面详细阐述国内锂电池CAE软件未来发展的突破口。文章结构要点如下：
现有锂电池仿真技术现状及相关商业软件
锂电池仿真技术前沿发展趋势
多尺度仿真
数值模拟算法
CAE仿真软件发展趋势
功能和架构
多物理场耦合、多尺度仿真
全流程协同
云仿真及SaaS
国内锂电池CAE仿真软件的突破口
建模及数值模拟
工程经验积累
开源是否适用于国内CAE仿真软件发展
锂电池CAE仿真软件市场分析
展望
一、锂电池仿真技术现状及相关商业软件
目前锂电池仿真模型主要为以Newman伪二维（P2D）模型为主的电化学模型、等效电路模型和热电耦合模型这三大类，此外还包括电化学-力学耦合模型等。
其中以Newman伪二维（P2D）模型为代表的电化学模型主要用于电极与单体电芯的设计和性能仿真，通过一系列偏微分方程组来描述锂离子电池内部发生的电化学反应，包括锂离子固液两相扩散、电解质中锂离子的迁移、固液界面的电荷转移等过程。P2D模型包括以下6个方程：
基于Fick第二定理的固相扩散方程
液相扩散方程
固相电势方程
液相电势方程
电荷守恒方程
Bulter-Volmer动力学方程
等效电路模型是将电池简化为电路网络来描述电池，结构简单，参数辨识复杂度和计算量小，是目前电池管理系统开发和电池在线状态估计领域应用最为广泛的模型。
热电耦合模型，是充分考虑了电池产热温度对电化学过程的影响，可以对电池电化学过程和性能进行更精准的模拟，可以用于电池单体、电池模组的热管理仿真。
目前市场上的锂电池仿真软件内置的机理模型大都包括以上三种仿真模型。主流的仿真软件包括COMSOL、Autolion、西门子的BDS和star-CCM+、达索的Abaqus以及ANSYS Fluent。下面将简要介绍这些软件。
COMSOL
COMSOL是一款可以实现多物理场耦合仿真的软件，电化学建模方式包括基于均质多孔电极结构的模型和基于非均质的模型，可以建立从零维到三维的电化学模型（或者称之为准三维模型），可以建立从极片级别到电芯级别到模组级别甚至到系统级别的仿真，并且可以和温度场、流场耦合，同时软件也包括了等效电路模型。
值得一提的是，COMSOL软件具有自定义控制方程的功能，这对于做锂电池的仿真是很有必要的，比如容量衰减机理目前可能还没有一些定论，没有非常标准的经验模型或者方程模型去描述这个过程，这时仿真人员可以根据自身的经验或者查阅文献自定义添加修改控制方程进行仿真求解[1]。
COMSOL软件建模方法
Autolion
该软件原先属于EC Power公司，后被Gamma Technologies公司收购。EC Power创始人王朝阳博士是宾夕法尼亚州立大学终身讲座教授，目前正在研究锂电池驱动的飞行汽车。AutoLion建模方式包括了经典的电化学模型、等效电路模型，同时还提供一个电化学-力耦合的膨胀模型，该模型能够预测电池因活性颗粒材料在锂化过程中产生膨胀导致内部应力变化的情况。AutoLion还配置了电化学材料数据库，以此减轻实验室测试电化学性能的负担。
BDS及STAR-CCM+
BDS软件功能
Battery Design Studio简称BDS，BDS是一款电芯设计软件。BDS的特点是，在电极层面支持输入基于SEM扫描重构几何模型和随机构建的虚拟几何建模，
同时BDS还可以与STAR-CCM+中的BSM模块联合实现电化学和流/固体传热的双向强耦合分析，可以用于涂布辊压工艺仿真和热管理仿真。STAR-CCM+的流体仿真功能也支持模组和系统级别的设计需求。
与COMSOL不同的是，BDS不支持用户自定义修改控制方程，模型是固定好的，所以对于锂电池这个机理模型还在不断发展的领域来说，用户使用的友好度和适用性就相对弱了一些。
达索
达索电池相关仿真软件
达索由于过往收购的工业仿真软件很多，因此能拿出来很多不同软件形成一套从电芯到模组到系统级别的仿真解决方案。电芯设计方面是由Abaqus支持，Abaqus最新版本中的电化学模型是基于扩展的三维多孔电极理论 Porous Electrode Theory（PET） Newman本构模型。Abaqus本身在结构物理场上优势也在锂电池仿真中加以应用，可以通过热-电化学-结构多物理场耦合来对电芯3D模型的热电化学结构特性提供定量的仿真模拟，预测电芯的温度、电流、变形之间的耦合效应，避免电芯变形过大造成内部短路，还可以对电池模组、电池包的振动和冲击、跌落进行分析。PowerFLOW可以对动力电池的热管理问题进行瞬态精确模拟。
ANSYS
ANSYS电池仿真软件
ANSYS强项在结构力学和热管理的流体仿真，对于电芯本身的电化学反应仿真能力相对而言较为薄弱，没有提供独立的电芯仿真软件。在流体仿真用于热管理方面，ANSYS可以提供ROM降阶模型以缩短仿真计算时间，精度与经典的三维CFD方法接近，对于设计控制策略和开发BMS系统有较大帮助。
小结：总体上看，现有电池仿真软件仿真覆盖的尺度多集中在电芯及模组系统方面，对于电化学过程的仿真能力上存在一定的瓶颈，在业界部分设计实践过程中很难提供有效的指导，而突破这些瓶颈需要结合锂电池电化学模型的理论创新来实现。下面我们就会介绍锂电池仿真技术前沿发展趋势。
二、锂电池仿真技术前沿发展趋势多尺度仿真
现有的电池研发方式是以实验为主导的，通常需要耗费大量的人力、物料、测试机器等成本，测试和验证的周期很长。同时，现有的实验试错方法很难完全控制某个单一变量,也很难考虑到多个因素共同作用下的影响机制。而锂离子电池本身是一个复杂的电化学系统，电池性能受到多个尺度、多个物理场内不同因素的影响，而且这些因素往往是互相耦合的。
因此，提高锂离子电池的性能、合理优化电池材料和结构上的设计，就需要系统地研究电池内部各物理场的耦合作用机理，从多尺度范围上深入理解电池运行机理，建立数学物理模型，并通过数值模拟仿真技术，在电池材料本征特性（微观原子、分子层面）、活性材料颗粒、极片、电芯以及电池模组、电池包多个尺度上进行仿真模拟和设计优化。
下图展示了从材料探索到系统设计的多尺度设计和模拟[2]。
图 锂离子电池多尺度设计和模拟概况[2]
宏观尺度上电池模组、电池包及系统的仿真模拟发展相对成熟，下文中我们重点探讨微观尺度和介观颗粒尺度以及电芯尺度上的前沿进展。
微观尺度上，原子、分子层面主要采用的理论方法包括基于密度泛函理论的第一性原理计算（DFT）、分子动力学（MD）、蒙特卡洛模拟、相场模拟等。
其中，DFT常用于计算电极材料的结构稳定性、嵌锂电位、迁移路径及锂离子传输动力学和脱嵌锂相变等性质[3]。但是目前可以模拟的原子数量较少，和实际情况的匹配度还不够高。
分子动力学可以获得原子的位置和运动速度等信息，可以揭示材料中离子的扩散机制，特别是在探测电解液溶剂化结构方面具有天然优势，而离子电导率和介电常数也与电解液结构相关[4]。因此目前业界会使用分子动力学等方法来进行新型电解液开发时的初次筛选，即先确定一个大致的范围，之后再通过实验等方法进行精细的筛选，一定程度上缩短了电解液的研发设计流程和周期，可以节省一定的研发成本。但目前仍然要解决计算模拟成本较高、界面反应机理模拟仍很有限等问题。
在原子分子层面的计算材料模拟，国内不少高校课题组开展了很多工作，有的也开发出相应的仿真模拟软件，比如北大深研院潘锋教授团队自主开发了基于 GPU 高通量计算集群的第一性原理计算程序 PWmat，相比于VASP软件，计算速度更快[5]；华东理工大学团队开发的软件可以介入电极电解液界面反应的尺度，帮助筛选电解液[6]。
从颗粒尺度上看，在材料开发和改性的基础上，材料组分已经确定的情况下，优化电极的介观结构成为提高电极及电池性能的方法途径之一。因为即便是同一种类的正负极材料, 如果材料的微观结构不同，宏观上表现出来的电池性能也会不同。
如果想要深入研究电极结构对性能的影响，凭借现有的P2D模型无法做到。因为Newman的P2D模型的假设基于体积平均法，这种方法对电极复杂微观结构进行了简化，将锂离子电池多孔电极固液两相看做一种均匀介质，这使得模型忽略了电极内部反应速率不均匀性等问题，仿真的范围受到限制，因此无法进一步探究多孔电极介观微结构对电池性能的影响。
目前许多介观的电极结构模型和表征成像技术陆续被开发出来[7]。模型构建方法一般分为两类，一类是把电极颗粒采用随机堆叠方式构建出虚拟电极结构，逐步逼近电极真实结构，一般被称为颗粒堆叠模型，随机堆叠方法包括蒙特卡洛法等。FANG利用非均相的电极结构来计算等效参数，提出了扩展均相多孔电极模型，可以建立负极区域颗粒粒径分布与电池倍率性能之间的关系，并且因为没有直接基于非均相结构进行仿真，节省了计算周期和成本[8]。类似的，还有研究建立了二维的团聚体颗粒堆叠半电池模型[9]。
另一类是基于高精度层析成像技术如nano-CT、SEM等，获取真实的电极二维形貌图像后再重构出电极材料的三维微观结构，一般被称为几何重构模型。三维几何重构模型可以考察电极孔隙率和曲折系数的关系，探究不同的孔隙率对锂离子传输过程的影响[10]。
此外，还可以借助相场模型在电极颗粒尺度研究锂离子嵌入和脱出过程中的传输行为、应力变化规律，这对设计优化电极微结构来提升电极的倍率性能，即快充性能具有重要指导意义[11]。
通过材料颗粒尺度的三维重构结合锂离子电池电化学模型，可以更直观的研究锂离子的浓度分布、电势分布与电极介观微结构间的关系，相较于P2D模型其仿真结果更加贴近实际。比如构建包含颗粒尺度的三维异构电化学-机械模型，该模型能够同时考察颗粒尺度以及电极尺度中的电化学-机械耦合过程，可以辅助不同材料体系下活性颗粒和电极层结构设计[12]。同时由于考虑到颗粒尺度，这种基于颗粒尺度的电化学模型可以更好地和制程工艺相结合。
已有研究系统梳理了电极结构的孔隙率、迂曲度以及导电剂、粘结剂分布会如何影响电极和电池的电化学性能，总结了微结构-工艺-性能的关联关系，以及用哪些方法来优化电极介观微结构[13,14]。
图 锂离子电池电极制造工艺-微结构-性能关系[14]
但更为关键的是，需要建立电池性能与电极微结构以及工艺参数之间模型化的表达，比如正负极材料特征参数（颗粒结构、D10/D50/D90粒径指标、石墨负极的焦原材料等）、极片结构参数（极片孔隙率、孔隙分布、曲折度）与电池倍率性能、能量密度、循环次数之间的关联，能否建立相应的数学物理模型，并以此为基础开发一套仿真软件系统或者叫平台，来系统地指导材料选型与电极设计。
这方面欧洲的Alejandro A. Franco团队做了一系列的工作，建立了一个模拟锂离子电池制造过程并预测其电化学性能的多尺度仿真平台。该仿真平台涵盖了电极介观结构生成、网格划分、有限元或有限体积以及格子玻尔兹曼（LBM）和离散元（DEM）的数值模拟仿真应用[15]。
该平台采用粗粒化分子动力学（CGMD，coarse grained molecular dynamics）模型用于浆料制备和电极干燥过程介观结构的生成，从电极制备工艺追溯模拟电极介观的生成，而不是通过前述的两类模型构建方法，因为成像技术或者模拟产生的介观结构并不是电极的全貌，一般都是根据电极样品的平均特性来表征电极特征。而且CGMD模型考虑了活性颗粒（AM）和碳胶相颗粒（CBD），可以评估CBD的空间位置及其对锂离子传输效果这两点对于整体电化学性能的影响[16]。
图 多尺度仿真平台
干燥后的电极介观结构会再通过离散元法（DEM）来模拟辊压工艺过程、LBM（Lattice Boltzmann Model）来模拟注液过程，分析辊压和注液对电极介观结构的影响，包括孔径分布、迂曲度和颗粒排列等。最后，利用有限元或有限体积法进行单体电芯尺度上的电化学仿真。如此基于3D电极介观结构建立电化学模型，可以分析电极辊压程度和注液过程对宏观电化学行为的影响，可以建立辊压和注液工艺、电极介观结构及电池整体性能之间的联系。从而帮助设计优化材料选型、电极结构和工艺过程[17,18]。
Alejandro A. Franco团队还开发了电池数值模拟前处理中的网格划分工具，该工具内置了基于MATLAB开发的体素化网格划分算法，可以将输入的三维电极介观结构（无论是扫描还是重构得到的）离散成若干个四面体网格，之后网格可以输入到COMSOL中进行宏观尺度上的有限元仿真模拟。INNOV划分网格时可以充分考虑孔隙以及活性材料颗粒（AM）和碳胶相颗粒（CBD）的状态，而不是简单的把AM和CBD简化为一个相。INNOV还可以用来生成全固态电池的结构模型[19,20]。
图 INNOV网格划分算法工作流程
此外，该团队还综合利用DoE试验设计（Design of Experiement）、仿真模型和机器学习算法的混合建模方法，来预测材料、电极制造和电池性能之间的最佳组合。即将DoE试验和仿真模型得到的结果，经过一个数据驱动的随机电极介观结构生成器扩大样本，再将这些样本用于训练机器学习算法，以求得到制造工艺参数与电极性能之间的关系。有效评估辊压压力、电极组分和初始孔隙率对极片孔隙曲折度、离子/电子电导率等电极微结构特征的影响，进而发现其对电池电化学性能的作用规律[21]。
单体电芯尺度上，可以结合前述颗粒尺度模型进行全极片的仿真分析，分析极片层级的不均匀性对电池热分布、寿命及安全性的影响。针对电池热管理，建立更高保真度的电化学-热耦合仿真模型，以此进行电池结构优化设计及其热管理系统设计。此外，为了深入了解电池老化机制，学界也在持续构建新的电化学-力学耦合模型和析锂模型等。
小结：
提升锂电池正向设计能力需要从材料-结构-工艺-性能这个四面体关系出发。材料基因组、DFT、MD等方法更多是从材料本征特性出发，筛选出新型正负极、电解液以及粘结剂等材料，开发新的化学材料体系，满足新型电池能量密度、功率或者安全性上的要求。颗粒尺度则更多是从电极微观结构出发提高电池整体性能，并且可以与加工工艺结合，优化工艺参数，实现设计与制造两端协同优化。
之前所提到的COMSOL等多个商业仿真软件都是在单体电芯及模组和电池包这些宏观尺度上运用有限元FEM、有限体积FVM等方法进行仿真模拟。而锂电池仿真模拟的前沿方向是要向更微观的层面探索，基于从微观、介观上发现的电化学机理来构建更为精准的数学物理模型，进而开发仿真模拟软件。这一点是国内锂电池CAE软件发展最重要的突破口之一，我们将在下文中继续探讨。
数值模拟
数值模拟是求解理论模型的方法手段，目前一些相对新兴的数值模拟技术被用来探究介观尺度上的电化学反应过程机理[22]，同时一些模型降阶、时间离散等计算加速方法也被应用进来，以达到兼顾模型精度和计算效率的目的[23]。
数值模拟算法方面，LBM可以用来研究电极介观微结构对于电池电化学性能的影响。比如利用LBM模拟锂离子和电子的传输过程，研究极片颗粒粒径和孔隙率对锂离子浓度分布和放电深度的影响[24]，以及模拟电解液在一个3D锂离子电极模型中的浸渍过程，考察电极结构对电解质润湿速度的影响[25,26]。相较于FEM/FVM，LBM网格生成效率更高，支持解决复杂的几何形状、边界条件和多孔介质，其在多相流多组分仿真的优势可以在电极介观尺度上发挥出来。
而且LBM这种算法本身就具有极强的并行计算能力，支持并行数据分析，非常适合于现有的并行计算集群，可以将LBM和并行计算硬件资源结合起来，进一步加快模型求解速度。
计算加速方法方面，有学者提出一种准显式非线性多尺度电池模型GH-MSMD，以提高先前开发的MSMD的计算速度，在时间离散的方法下，无需传统计算方法中的嵌套迭代，该模型可以在颗粒、电极、电池以及电池模组的尺度上进行仿真[27]。
还有学者使用降阶的多尺度多维模型（MSMD），采用基于伽辽金投影法的模型降阶方法，降低了计算的复杂性，并通过实验数据验证该模型的高保真度，结果表明，该MSMD模型的计算复杂度显著降低，并且提供了高精度的电化学和热性质分布情况[28]。
三、CAE仿真软件发展趋势
CAE仿真软件一直在不断发展，一些重要的发展趋势值得国内CAE软件公司参考。如果在锂电池领域开发国产自主的CAE仿真软件，除了具备前文中所提到的需要将前沿电化学理论参数化表达，如果进一步形成系统的代码以及开发相应的仿真软件，依然需要符合CAE软件开发的一般规律，开发出来的软件产品需要具备比肩甚至超越国外CAE软件的性能。下面先就CAE软件的产品模块和功能特点进行分析。
功能和架构：
从大的方面来说，CAE软件通常是综合了数学、物理、电化学等多学科理论基础、计算机科学、工程应用实践三方面的知识。对于现实客观世界的建模通常依靠物理、电化学等基础学科理论，深入理解描述物理、电化学等过程的原理理论。原理理论的开拓通常需要无数数学家、物理学家、化学家以及科研工作者持续的探索和归纳，不断提出对客观规律更为精准的描述方法。电化学过程目前普遍采用Newman提出的伪二维模型来描述，遵循电荷守恒和物料守恒。流体仿真中描述流动的底层物理规律是动量、质量守恒，其中N-S方程被用来描述动量守恒过程，连续性方程描述质量守恒。每一种物理场都可以用若干模型和方程来描述，当涉及到多个物理场时，还要建立耦合模型，构成偏微分方程组再进行求解。
这些现实客观世界的建模所设立的方程通常为偏微分方程，从这一点来说，偏微分方程是人类用来描述客观世界的工具，而CAE仿真软件就是要通过计算机科学技术来实现对客观世界的建模、求解、结果展示以及优化设计。
CAE软件从产品角度来看有三个重要的组成部分，分别是前处理器、求解器和后处理器。后处理器用于展示CAE求解结果，这里通常运用计算机图形学技术来开发。CAE软件的核心在于对现实现象的精准建模以及实现高保真度的数值模拟求解。CAE软件的仿真质量和数值模拟的质量直接相关。
数值模拟计算一般分为三个环节：网格离散（网格划分）、边界条件设定和求解过程本身。数值模拟求解的核心在于网格离散和数值算法，因此前处理器中的网格划分模块和求解器是CAE软件中最为关键的两个部分。
首先，数值计算需要输入高质量的网格数据，否则就会是“garbage in, garbage out”，网格剖分的好坏直接决定了仿真质量的高低，因此网格生成的算法技术非常重要。而且网格生成的密度还要结合实际工程应用场景，平衡计算精度和计算效率。目前实际仿真场景中前处理仍主要依靠人工处理，处理时间较长，往往40%左右的时间都花在网格处理上面。目前业界主要通过自适应网格加密划分技术和AI来提高前处理中网格划分的效率。
求解器的开发实际上是运用C++/Fortran等语言将数值计算方法编写成软件程序，求解过程就是求解程序在硬件上运行，求解的对象是基于网格数据生成的大规模线性方程组。求解器的鲁棒性和收敛性至关重要，计算求解如果很容易发散，得不到收敛的结果，那么开发出来的仿真软件市场反响就不会很好。目前很多数值计算方法已经相对成熟，比如有限元法、有限体积法等，这些也都是现有商业软件广泛应用的数值方法。而面对电池领域尚未得到很好解答的一些问题，比如涉及到介观尺度方面的仿真模拟问题，就可以运用一些相对新兴的数值解法如LBM、SPH等，这在前文中已详细介绍过。
另一方面，实际仿真过程的计算时间有可能长达几天甚至几个月，仿真工程师都希望仿真的速度能够进一步提升。目前业界在通过降阶模型（ROM）和高性能计算等技术来缓解“仿真计算速度焦虑”。
简要总结一下，自主开发的CAE软件需要具备的功能特点：
前处理器：支持生成多种网格类型（四面体、六面体等等），易用性好，划分速度快；图形界面操作方便，交互页面简单易懂、方便工程师快速设置求解模型的多种边界条件。
求解器：收敛性和稳定性，不容易发散；计算速度快、计算精度高，误差小
后处理器：图形引擎稳定性高，可生成各种后处理图形和动画，可视化效果好
除了软件产品需要具备上述功能特点，技术支持团队要能提供高质量的仿真应用支持服务，要保证仿真软件应用效果和用户应用体验，以此保障交付和订单的可持续性，特别是在工业仿真软件也在向SaaS转变的趋势下。要搭建完善的客户交付体系，在用户培训、软件试用以及技术支持的各个环节都要能快速响应、解决问题。
多物理场耦合、多尺度仿真
仿真已经从单一物理场仿真演进为多物理场耦合仿真，考虑两种或多种物理场的交叉作用和相互耦合，多物理场耦合仿真会涉及到模型交互、几何网格匹配、求解等多种挑战。以电池为例，就涉及到物理、电化学、流体、机械结构、电磁兼容等诸多物理场。
未来仿真不仅仅是多物理场耦合，也将会是从材料到系统层次覆盖多尺度的，和前述我们分析电池仿真类似的还有半导体仿真，半导体器件仿真也在将器件性能与材料特性联系起来，系统研究材料、几何形状以及工艺的变化将如何影响器件的电学性能，以此优化器件设计。应用材料公司在2021年提出Materials to Systems Co-Optimization，希望实现从材料到系统的多尺度协同优化，以此确定最佳工艺路线和参数（覆盖前道、中道及后道中多个工艺环节）。
国外工业软件大厂也在多尺度仿真上早有动作，2014年达索收购acclrys，现更名为BIOVIA，BIOVIA主要侧重生物科学。2020年西门子收购了计算化学公司Culgi，Culgi软件可以提供量子化学和分子模拟功能。
全流程协同仿真与测试协同
仿真是企业研发的重要一环，除了提供高效的仿真分析，仿真软件还要提供仿真流程与数据管理平台，有效管理海量的、不同类型的仿真文档和数据，建立分析文档与产品模型的对应关系，帮助企业建立专有的仿真知识库和流程规范，提高对仿真知识、流程的可复用程度。
研发不仅仅是仿真。研发过程中仿真-测试共同产生的海量数据蕴藏着重要价值，因此工业仿真软件不仅仅要沉淀工艺经验知识的仿真数据，还需要沉淀研发管理、设计仿真的数据管理经验，将设计-仿真-测试全流程标准化。
仿真软件除了要提供杰出的仿真技术为设计提供指导依据外，还可以深入研发测试环节，提供仿真-测试的综合服务。比如西门子2012年收购的比利时LMS公司，就是一家可以为汽车企业客户提供NVH方面综合的仿真-测试解决方案。LMS提供了测试所需要的软硬件产品，其中就包括测试数据管理系统，可以最大限度地减少客户处理测试数据和创建报告所花费的时间，帮助客户提高整个组织的协作效率。
研发数据管理问题对于电池企业愈发凸显，由于电池研发本身是一个复杂工程，研发过程中会产生的TB级以上的数据量，如何有效地管理这些研发测试数据，为数据分析和引入AI算法做好基础工作，是目前电池及电池材料企业研发管理需要解决的一个重要问题。
目前多数电池及电池材料企业仍然主要以纸质或者借助简单的Excel表格存储管理研发数据。少数头部企业通过上线研发试验管理系统来提高研发数据管理水平，保证测试数据的可追溯性和可重用性。在部分电池企业，这类管理系统会覆盖电池常规测试、电池表征测试、电池失效分析等方面。少数材料企业希望以此实现材料包覆、预锂预镁等工艺的研发测试管理数字化。电池及材料企业都希望借此提高研发效率、降低研发运营成本[29]。
仿真软件还可以增加与测试数据的对比以获得更好的工程洞察力。比如西门子的Teamcenter就包括创建虚拟传感器的技术，客户可以在难以放置真实传感器的区域获取数据，Teamcenter内置的数据管理软件可以汇聚企业测试得到的真实数据和仿真数据。通过将设计、仿真和测试数据汇集在一起，在软件中创建验证序列，企业客户可以快速定位问题、更好地评估设计方案。
材料数据库
仿真不可避免会涉及到各种材料，所以部分仿真软件配置相关的材料数据库，比如COMSOL和ANSYS，以ANSYS为例，ANSYS于2019年收购了Granta Design公司，并将它重组为ANSYS的材料事业部门。Granta Materials同时融合了多种标准材料数据库，能够为产品设计提供丰富的材料数据信息。这些数据库涵盖了通用材料、航空航天、塑料、医疗器械等多个领域。同时支撑企业自有数据录入。
总结一下，仿真软件公司介入研发测试数据管理具有很强的重要性：研发数据很重要富有研发价值；仿真-测试综合服务有利于为客户提出更多有价值的研发建议，提高客户粘性；未来引入AI和计算材料学方法需要良好的数据基础。此外，仿真软件会配置相关材料数据库来减轻企业仿真负担、提升仿真精度。
对于国内锂电池领域的仿真软件公司来说，可以在提供电池测试数据管理功能模块的基础上，通过建立电池表征管理和电化学参数库，实现电池测试数据和材料数据的结构化存储，为之后将测试数据和仿真所需参数结合起来打好基础。统一的研发数据管理分析平台，为用户提供自动化、标准的测试和仿真分析报告，帮助电池企业实现电池研发数据的全过程追溯，以及跨部门、跨组织的研发协同。
而且电池研发也会涉及到种类繁多的金属和非金属材料，不同供应商提供的同种材料、不同工艺制备出来的同类型材料都可能在材料属性特征上存在差异，加上掺杂、包覆等多种工艺，使得电池材料的管理也非常复杂。电池仿真软件如果能够帮助企业有效管理研发所用到的材料数据，综合企业内部的试验、设计、历史积累数据和企业外部材料信息数据资源，最终形成一个覆盖范围广泛的企业级电池材料信息管理系统，帮助企业更加方便地获取准确的材料数据，将有效提升企业电池研发仿真精度与效率。
设计仿真与制造工艺、产品运行等环节的协同
整体上看各行业仿真与制造工艺的协同趋势已然显现，其中以半导体的DTCO为代表，这种协同不单单是一个企业内部跨部门、跨组织的协同，甚至有可能是跨上下游的协同，因此需要第三方的工业软件公司来承担起作用。锂电池领域设计仿真与制造工艺协同也有所发展，但是需求主体和强烈度、发展节奏和成熟度与半导体行业DFM和DTCO的有所不同。
一个好的设计必须要考虑制造环节的工艺过程，而设计与工艺的协同就需要导入仿真技术，特别是对于工艺变化很快的领域。以动力电池为例，工艺变化速度较快。目前实验验证的试错法又无法全局考虑问题，会导致制造现场不断调整参数。而且新方案测试耗时也很长。一个新的材料新配方去做验证可能需要12个月左右，导致新产品开发和产业化节奏较慢。因此，必须导入仿真技术，实现设计仿真和制造工艺的协同，加速推动产品的正向设计。
目前面向制造工艺的仿真技术有下图中所列的五大类[30]：
面向制造工艺的仿真模型
同时，仿真要实现与设计、制造、运行的全流程协同，在产品设计、生产工艺、质量测试、实际运行乃至产品回收等各环节都要进行相关仿真。这就意味着，不仅仅是在设计仿真过程要建立数字化的模型，而是要形成一个全生命周期的数字化模型，不断逼近物理实体状态，辅助实际决策。以电池为例，除了单体电芯级别的仿真模型之外，还需要将从电池到PACK到电池管理的仿真融合起来。这对仿真的实时性、精度和效率都提出了非常高的要求。
仿真要融入产品实际运行的环节过程中，就要与实际业务的应用场景紧密结合，比如通过工业物联网技术采集实时数据，再通过仿真技术实时提供仿真预测，辅助实际业务的决策。例如在电池领域，就可以考虑将电池实际运行的工况数据纳入仿真体系中来，除了用于实时的寿命预测和健康管理之外，还可以将老化数据与仿真模型进行对照，结合机器学习进一步优化仿真精度，还可以反馈优化设计和工艺。
随着上下游协同性的增强，仿真软件的使用者将从单纯的仿真工程师拓展到工艺人员等其他部门乃至上下游企业。以电池行业为例，可能电池厂的电芯工程师、工艺工程师要和上游的材料工程师、下游汽车主机厂的工程师和设计人员一起在仿真软件上探讨如何优化电芯的设计方案。
仿真反馈设计优化
仿真的目的在于优化产品设计方案，当前仿真、设计与优化三者结合的趋势越来越紧密。仿真软件目前会通过提供多种方案的评估对比，提供仿真结果辅助设计参数的优化，未来将会有更多和业务场景深度结合的优化应用出现。
小结：
无论是多物理场还是多尺度仿真，还是和测试、制造工艺等全流程结合协同优化，目的都是为了增强仿真置信度、加强仿真在研发设计中的指导作用，即让仿真辅助设计优化甚至决定材料的选取、工艺参数的设定、器件乃至系统的设计，这是当前非常重要的发展趋势。
以长安汽车为例，长安汽车对标福特汽车、通用公司建立CAE仿真置信度5级评价体系，第一级为由试验验证设计，不做仿真，第二级为运用仿真预测变化趋势，第三级为仿真筛选优化方案、减少试验次数，第四级为仿真筛选试验，试验只做一次，第五级则是由仿真直接验证设计，无需试验。对照这五级标准，如前所述锂电池行业目前普遍仍以实验试错法为主导[31]。
云仿真和SaaS
当前仿真软件也在逐步走向云端，相较于本地仿真，在云端仿真对于企业用户有以下几方面优势：
对于超大规模模型的仿真，提交到云端仿真可以进行多核并行计算，计算效率提升会非常明显。借助弹性的云计算功能，用户可以根据需要同时运行尽可能多的模拟。此外，用户可以随时按需扩展计算资源。
计算资源来自云端，可以为企业用户节省大量的硬件成本
通过“用户-角色-权限”的授权方式，即为用户分配角色来分配相应权限，可以简化常规的赋予和取消等权限管理，减少系统开销的同时有效保障企业的数据安全
项目所有相关人员都可以在云端软件内实时查看相同的仿真模型数据，有效增强用户之间的协作。
便于企业用户进行分布式存储备份和版本管理
用户可以在任何地点参与仿真操作，提高了办公灵活性
节省软件安装、更新成本
对于仿真软件开发公司来说，选择交付云端SaaS版仿真软件也是一个不小的挑战，会带来以下转变：
SaaS交付的销售价格将会更低，企业短期内收入会承受一定压力。
如果产品体验不佳，用户很可能取消订阅，企业需要拿出比“销售永久license时代”更好的客户交付服务，确保客户使用体验长期维持在高水平。因为这不再是一锤子买卖。
云端页面的交互显示十分重要，这对仿真软件企业在图形渲染、软件架构技术方面提出更高的要求。
近年来越来越多的工程师开始采用云端仿真，根据ANSYS的报告数据，52%的受访工程师表示在设计仿真过程中所面临的最大业务挑战是如何缩短设计周期，为了加速完成一些规模较大的仿真任务，工程师必须要获取大量的计算资源。在2014年的报告中，只有10％的工程师使用超过32个以上的内核，而2021年有44％的用户使用了12个以上的内核并行处理其最大的仿真应用程序，18％的用户使用的内核数量超过36个。中大型公司对多核计算资源的需求表现更为明显。同时工业仿真计算场景已经从单个工作站的单机模式逐渐演变为包含工作站、笔记本、集群和云端的复杂混合环境[32]。
在解决仿真效率问题方面，云技术和HPC（高性能计算）是紧密结合的，HPC硬件部分包括CPU、GPU、NPU等，软件部分主要解决集群资源调度问题。目前云厂商如阿里云，腾讯云等会提供开放式的云端硬件计算平台，将商业CAE仿真软件安装在云端HPC服务器上，按照资源使用时间收费。也有第三方公司如国内的速石科技和国外的Rescale等，比如速石科技就是综合多家云厂商资源和多种仿真软件，为企业用户提供集群运行仿真服务，解决企业资源峰值需求，避免过度投资或者预估资源不足的情况。
国外云端CAE软件公司有Simscale、Onscale、Designworld、Caeplex、Ceetron等，以Simscale为例，其采用SaaS模式进行交付。Simscale希望通过SaaS交付来为用户进一步节省下IT资源的部署投入，为工程师提供另一条更低成本的选择，而不是只能高价购买仿真软件的license。Simscale可以进行多物理场仿真，覆盖结构、热、流体等领域。但是，Simscale的求解器模块采用开源的OpenFOAM和CalculiX，OpenFOAM用于流体仿真，而CalculiX用于结构力学仿真，这意味着Simscale的仿真求解功能有限，只能解决一些基本问题，无法向高端市场跃进[33]。下图为Simscale与其他部署类型仿真软件之间的对比。
Simscale软件特点
国外大型仿真软件公司近年也一直在云端仿真方面持续推进，达索将自身不同仿真领域的软件集成到3D EXPERIENCE平台上，支持4-16核的本地计算机并行计算和云端计算，对于超大规模模型，如果用户想提升计算速度，可以将模型提交到云端计算。
ANSYS在今年4月收购云仿真供应商Onscale，意图将Onscale的云技术与自身先进的仿真求解功能结合起来为客户提供服务，用户通过web就可以访问。ANSYS今年5月还宣布和AWS合作开发基于云端的Ansys Gateway 仿真解决方案，发展云端高性能计算，推出EDA、CAE和CAD云端解决方案。种种动作表明ANSYS似乎想要搭建统一的云平台，把自身各条业务线产品都放到云平台上，客户可以在这个平台上进行设计仿真的所有操作，这一步可以说要比达索的3D EXPERIENCE平台更加贴近云原生。
实现更为高效的云仿真还需要面对很多挑战：仿真协同方面，如何有效应对大规模复杂模型仿真，不同领域仿真模型实现高效耦合；易用性方面，如何集成多种仿真平台工具的并提供简单易用的使用方式；作业运行方面，如何采取有效的仿真应用资源调度方法来提高仿真应用运行效率；网络化方面，未来云端仿真如何更好地和物联网实际数据融合起来等[34]。
面向电池领域的仿真软件也需要考虑利用云和HPC技术来增强用户项目组内部以及和上下游之间的仿真协作、提升用户仿真效率，特别是注重利用云端仿真技术实现电池数据的全生命周期管理。对于仿真软件来说，上云和SaaS是成为行业头部企业的必要非充分条件，技术上的突破才是根本，即要在理论模型和数值模拟算法上立住脚。
四、国内锂电池CAE仿真软件的突破口
一方面电化学建模逐步深入到电极介观尺度，另一方面一些相对新兴的数值模拟技术被用来探究介观尺度上的电化学反应过程机理。国内锂电池CAE软件应当聚焦这两个方面进行突破。同时要使用恰当的模型降阶、时间离散等计算加速方法，兼顾模型的精度和计算效率。
一是不断优化仿真模型及其控制方程，及时跟踪电池仿真在微观、介观尺度上的前沿进展，将精度更好的理论模型内置在软件之中，并开发出适配电池领域的网格划分工具。其次是可以向COMSOL学习，保持软件的开放性，这一点是指在建模阶段仿真工程师可以自定义修改设立控制方程组（偏微分方程组）及其假设条件，而不是只能采用软件内置的方程组。软件不断跟进业界的先进实践经验，通过加强与业界人员的合作来优化迭代自身软件求解器的性能。相较于其他成熟的仿真领域，这一点对于电池领域的仿真软件更为凸显。
求解方法方面注重运用新的求解方法，并将多种数值算法结合起来，比如LBM、DEM、FEM和FVM 结合起来，并注重数值计算方法和工程实际业务场景深度结合。同时工业仿真软件需要权衡精度和效率，这就需要恰当地使用降阶模型、伽辽金投影法、时间离散方法如龙格－库塔法（Runge-Kutta methods）等计算方法，尽可能确保在不损失仿真精度的情况下提高计算效率。
除了理论模型和数值算法，仿真软件还需要注重工程经验的积累，特别是对于电池这一非线性的复杂系统来说。因此，国内锂电池CAE软件公司一方面需要在产品功能上加强与实验测试数据的结合，为设计和仿真人员提供更便捷的仿真服务。这里具体来说，电池仿真通常需要大量参数输入，部分参数需要标定和实验以及文献参考得来，如果积累了大量的测试数据，就可以提供一个丰富的数据库，更加方便快捷提供模拟仿真所需参数，避免因为仿真人员标定出现问题带来较大的偏差，进一步缩短设计验证周期。
另一方面，国内锂电池CAE软件公司需要注重加强与电池企业的合作，更好地积累测试和实际制造的数据，以此优化仿真软件性能，更好地实现设计仿真与制造工艺协同。总之，要充分利用好我国掌握锂电全产业链这一庞大制造规模的优势，因为海量测试和制造数据中蕴藏着巨大的数据优势，利用好这些数据资产，有利于国内锂电池CAE软件公司加速发展起来。
综合本文前述内容，锂电池仿真软件的突破，要实现多尺度、多物理场、全生命周期的仿真服务，同时要利用好工业物联网和云计算技术，将电池的设计、仿真、制造以及使用过程中产生的海量工艺技术、工况数据形成数字化资产。
锂电池仿真软件不仅仅担负着仿真驱动正向设计的功能，也是推动整体锂电池领域研发数字化进程的重要力量。由独立于上下游企业主体的第三方软件公司驱动行业研发数字化、通过标准的流程、功能完善的仿真平台带动，实现上下游研发的网络化协同。
目前国内已经出现一些锂电池仿真软件公司，如易来科得、屹艮科技、鸿阳智能、海仿科技等。
实现电池领域的多尺度多物理场耦合仿真道阻且长，需要多学科人才、知识积累乃至多个细分软件工具的融合，参照COMSOL的发展历程[35]（COMSOL产品发布历程 (comsol.com)），这将会是一个长达20-30年的过程。
开源问题
CAE仿真领域有不少开源软件，锂电池仿真领域就有TauFactor、OpenPNM等开源软件。关于开源是否能够加速国产CAE仿真软件的发展，也曾被多次讨论过，这里简要表达我们对工业仿真软件领域开源的看法：
软件开源能否提高国产工业软件迭代升级、向欧美成熟工业软件追赶的速度？
我们目前认为是不能。一般基础软件通过开源获取技术迭代助力的逻辑并不适用于工业软件。首先，工业软件的底层核心在于基础理论和数值算法，这两方面的理论突破和算法创新才能从根本上实现工业软件的技术突破，很难通过无数软件开发人员的使用、贡献代码来提高CAE软件的性能，比如仿真计算速度更快、收敛更好、精度更高。
其次，仿真软件并不是一个互联网研发编写程序时需要用到的基础软件，而是一个受众面相对较小的专用软件，并且仿真软件代码编写的门槛很高，通过开源无法像互联网开源基础软件获得很多程序员的开发助力。
此外，互联网基础软件通过源代码开源吸引广大的开发者，这些开发者多数也会转变为客户，意味着基础软件的开源本身就是一种营销手段，开源基础软件无需付出高昂的销售成本就可以获得大量的用户。但是对于工业软件来说，代码开源并不意味着工程师就会使用这款软件甚至成为付费用户。由于制造业的行业属性，工程师需要选择稳定性更好、仿真质量更佳的软件，免费并不能构成一个富有竞争力的因素。
使用开源软件（组件）可能存在的弊端：
从技术研发角度看，如果前处理和求解器部分采用开源软件，相当于将技术核心命脉交在了别人手中，技术体系的更新完全依赖于开源软件的迭代升级。
从产品功能角度看，工业软件需要具备高可靠性和优异性能，并能与实际工程应用场景深度结合。开源软件通常自身性能和稳定性较低，一旦面对整体非常复杂的大型模型仿真，使用开源软件很可能出现计算不容易收敛或者求解速度过慢等问题。此外，开源软件通常缺乏大量的实际应用案例和帮助文档，可能无法回应仿真工程师的实际需求[36]。
从软件架构角度看，如果在某些功能模块采用开源软件（组件），也可能会出现架构耦合上的问题，软件升级后也会涉及和其他功能模块协同的问题，甚至会需要调整开源软件的架构，如此一来需要投入很多研发资源，结果可能得不偿失，还不如一开始就选择自主研发。
自主开发才是正途。这是一条少有人走的路。或有企业在开源软件基础上二次开发，套上一层壳就宣称自己是国产替代。这种做法只是看上去在走捷径，实际上是选择依附在其他公司的技术体系内，企业并未形成基于自身实际经验的产品原始研发能力。只有当企业以自主研发理念创新、性能先进的商业产品为目标时，企业才可能产生更强的创新动力和学习能力，才能在自主开发产品中突破技术瓶颈、逐渐掌握工业软件的研发能力。
自主开发也不意味着完完全全从头做起，除底层技术需要自身突破外，部分非核心软件模块可以考虑采用已经非常成熟的商业开发工具，比如GUI组件和图形渲染方面。在软件生态上也要加强合作，开放仿真上下游的第三方软件API接口，做好数据兼容，进一步增强软件的易用性和包容性，融入现有的设计仿真工具链中，降低工程师的软件使用成本。
五、锂电池CAE仿真软件市场分析
前文我们从理论、技术、产品三个方面进行了详细阐述，下面从市场侧进行简要的分析。
软件的需求问题：通常电池企业的制样测试周期长达8-36个月，包括物料、测试通道设备、人工等在内的耗费成本甚至可能要上亿元。而仿真软件减少几次制样测试的成本基本可以就完全覆盖掉软件的采购价格，为企业带来的经济效益和投入产出比是非常高的。但是要注意用户对于仿真软件的精度、稳定性要求很高，工业仿真软件不存在所谓明显意义上的中低端市场。
锂电池CAE仿真软件国内总体市场规模可以通过国内锂电池企业数量、软件购买数量和软件单价（单机版）或订阅费用（按年计算）估算获得，如果假定以SaaS形式交付，具体软件购买量可以通过现有锂电池企业仿真人员数量、使用频次及时长估算得到。
从市场用户拓展来看，多尺度以及和制造工艺协同的仿真，可以使仿真软件串联起锂电产业上下游，未来有希望可以覆盖整车企业、电芯企业及电池材料企业。
展望
我国已经建立起了锂电池行业材料-电芯-模组-新能源汽车的完整产业链，中国制造的电池产品远销欧美发达国家市场以及印度等新兴市场，部分电池企业也和国外的主机厂展开合作，将电池制造技术带到欧美，由此可见中国锂电行业已经实现了产品输出和制造技术输出甚至是资本输出。
但是从产业竞争的视角来看，锂电池的设计仿真这一核心技术仍未掌握，现有成熟的商业仿真软件仍属海外公司，国外科研人员和公司也都在加紧开发更加前沿的锂电池仿真技术，希望从源头的设计端突破，重新掌握锂电产业的主导权。所以，掌握设计仿真技术将是我国锂电产业未来发展的一个重要目标。占据正向设计仿真技术这一产业发展的制高点，将有利于推动我国锂电产业从依靠制造优势转变为依靠技术创新优势的发展方式。
锂电池仿真技术无论是在理论上还是数值模拟方法上都存在拓展的空间，这就为国内锂电池仿真软件发展提供了技术研发上的条件和空间，而国内锂电全产业链的庞大制造规模优势，潜在的测试数据规模优势，也为国内锂电池CAE仿真软件的发展提供了丰厚的土壤。新兴制造业发展引发新产品和新工艺开发，进而产生新的设计和仿真需求，为促进仿真软件的发展提供了市场条件。从这个角度上说，锂电池仿真是国内CAE仿真软件的一个突破口。
工业仿真软件发展周期长、开发难度很高，以多物理场仿真软件COMSOL为例，公司成立于1998年，发展到今天也已经走过近30年。开发工业仿真软件需要数学、物理、化学、流体力学、材料科学、计算机技术等众多基础科学和工程科学的科技人才。而且工业软件只有迈向高端这华山一条路可以走，工业仿真软件企业需要从创立之初就秉承着研发高端技术产品的信念，才有可能从小到大、从弱到强发展起来。
唯有技术持续创新发展，才能使产业不断走向繁荣。从原理出发，站在基础科学的前沿上实现理论工程化的实际突破，才有可能真正实现创新驱动的发展。工业仿真软件恰是会承担起这样的作用。
由于笔者时间、视野、认知有限，本文难免出现错误、疏漏等问题，期待各位读者朋友、业界专家指正交流。
文中部分业界观点获得六度智囊支持，在此表示感谢
参考文献
【智能制造会议报告-施翀】多物理场仿真助力锂离子电池研发 (qq.com)
Liu X, Zhang L, Yu H, et al. Bridging Multiscale Characterization Technologies and Digital Modeling to Evaluate Lithium Battery Full Lifecycle[J]. Advanced Energy Materials, 2022, Jun 15:2200889.
黄杰,凌仕刚,王雪龙,蒋礼威,胡勇胜,肖睿娟,李泓.锂离子电池基础科学问题(ⅩⅣ)——计算方法[J].储能科学与技术,2015,4(02):215-230.
Yao N, Chen X, Fu ZH, Zhang Q. Applying Classical, Ab Initio, and Machine-Learning Molecular Dynamics Simulations to the Liquid Electrolyte for Rechargeable Batteries[J]. Chemical Reviews. 2022
林海,郑家新,林原,潘锋.材料基因组技术在新能源材料领域应用进展[J].储能科学与技术,2017,6(05):990-999.
锂离子电池多尺度多物理场模拟方法发展与应用_哔哩哔哩_bilibili https://www.bilibili.com/video/BV1Lr4y1u7ud?spm_id_from=333.880.my_history.page.click
Chen, Z., Danilov, D. L., Eichel, R. A., & Notten, P. H. (2022). Porous Electrode Modeling and its Applications to Li‐Ion Batteries. Advanced Energy Materials, 2201506.
FANG Ruqing, GE Hao, WANG Ziheng, et al. A two-dimensional heterogeneous model of lithium-ion battery and application on designing electrode with non-uniform porosity[J]. Journal of the Electrochemical Society, 2020, 167(13): 130513.
王子珩. 团聚体堆叠型多孔电极模型构建与应用[D]. 北京: 清华大学, 2017.
Stephenson, David E., et al. Modeling 3D microstructure and ion transport in porous Li-ion battery electrodes[J] Journal of The Electrochemical Society , 2011，158(7): A781.
常力戈. 锂离子电池电极性能与颗粒微结构关联的相场模拟[D].中国科学技术大学,2021.
项李志. 颗粒尺度电化学-机械模型构建与应用研究[D].哈尔滨工业大学,2020.
巫湘坤,詹秋设,张兰,张锁江.锂电池极片微结构优化及可控制备技术进展[J].应用化学,2018,35(09):1076-1092.
李茂源,张云,汪正堂,谭鹏辉,刘兴鹏,张道琦,李光,解晶莹,周华民.锂离子电池极片制造中的微结构演化[J].科学通报,2022,67(11):1088-1102.
Ngandjong A , Rucci A , Maiza M , et al. A Multiscale Simulation Platform Linking Lithium Ion Battery Electrode Fabrication Process With Performance At The Cell Level[J]. Journal of Physical Chemistry Letters, 2017:5966.
Chouchane M , Rucci A , Lombardo T , et al. Lithium ion battery electrodes predicted from manufacturing simulations: Assessing the impact of the carbon-binder spatial location on the electrochemical performance[J]. Journal of power sources, 2019, 444(Dec.31):227285.1-227285.6.
Rucci A , Ngandjong A C , Primo E N , et al. Tracking variabilities in the simulation of Lithium Ion Battery electrode fabrication and its impact on electrochemical performance[J]. Electrochimica Acta, 2019.
Acna B , Tla B , Enpa B , et al. Investigating electrode calendering and its impact on electrochemical performance by means of a new discrete element method model: Towards a digital twin of Li-Ion battery manufacturing - ScienceDirect[J]. Journal of Power Sources, 2021, 485.
Chouchane M , Rucci A , Franco A A . A Versatile and Efficient Voxelization-Based Meshing Algorithm of Multiple Phases[J]. ACS Omega, 2019, 4(6):11141-11144.
Chouchane M , Franco A A . An Invitation to Engage with Computational Modeling: User-friendly Tool for In Silico Battery Component Generation and Meshing[J]. Batteries & Supercaps, 2021.
Duquesnoy M , Lombardo T , Chouchane M , et al. Data-driven assessment of electrode calendering process by combining experimental results, in silico mesostructures generation and machine learning[J]. Journal of Power Sources, 2020, 480:229103.
Ryan E M , Mukherjee P P . Mesoscale modeling in electrochemical devices—A critical perspective[J]. Progress in Energy and Combustion Science, 2019, 71(MAR.):118-142.
Bermejo R , Sastre P . An implicit-explicit Runge-Kutta-Chebyshev finite element method for the nonlinear Lithium-ion battery equations[J]. Applied Mathematics and Computation, 2019, 361:398-420.
Jiang Z Y , Qu Z G , Zhou L , et al. A microscopic investigation of ion and electron transport in lithium-ion battery porous electrodes using the lattice Boltzmann method[J]. Applied Energy, 2016, 194(MAY15):530-539.
Shodiev A , Primo E , Arcelus O , et al. Insight on Electrolyte Infiltration of Lithium Ion Battery Electrodes by Means of a New Three-Dimensional-Resolved Lattice Boltzmann Model[J]. Energy Storage Materials, 2021, 38(8).
Asa B , Fmza B , Jia Y , et al. Designing Electrode Architectures to Facilitate Electrolyte Infiltration for Lithium-Ion Batteries[J]. Energy Storage Materials, 2022.
Kim G H , Smith K , Lawrence-Simon J , et al. Efficient and Extensible Quasi-Explicit Modular Nonlinear Multiscale Battery Model: GH-MSMD[J]. Journal of the Electrochemical Society, 2017, 164(6):A1076-A1088.
Fan G , Pan K , Storti G L , et al. A Reduced-Order Multi-Scale, Multi-Dimensional Model for Performance Prediction of Large-Format Li-Ion Cells[J]. Journal of The Electrochemical Society, 2017, 164(2):A252-A264.
浅谈电池研发实验管理数字化成熟度模型的价值与应用 (qq.com)
Ayerbe E, Berecibar M, Clark S, Franco AA, Ruhland J. Digitalization of battery manufacturing: Current Status, challenges, and opportunities[J]. Advanced Energy Materials, 2022 May;12(17):2102696.
仿真驱动设计 (qq.com)
https://fastonetech.com/blog/cae-ansys-simulation-20210531/
SimScale – Wikipedia
段红,邱晓刚.网络化仿真及其发展趋势[J].系统仿真学报,2021,33(07):1526-1533.
COMSOL产品发布历程 (comsol.com) https://cn.comsol.com/release-history
专题讨论70--开源CFD软件和商用CFD软件_哔哩哔哩_bilibili https://www.bilibili.com/video/BV1Et4y147NX?spm_id_from=333.880.my_history.page.click
2022年11月29日，未来能源创投新风向大会将会正式举办，欢迎大家扫描下方二维码进行报名参会。同时可以进群提前了解更多大会相关信息。
WISE2022 未来能源创投新风向大会
更多活动信息及行业详情，请关注微信公众号“数字时氪”（微信 ID ：digital36kr），期待您的到来。
数字时氪
本文来自微信公众号“数字时氪”（ID:digital36kr），作者：张丞，36氪经授权发布。返回搜狐，查看更多
责任编辑：}