“数字化”和“数字化转型”这些词大概是从2015年左右开始热门起来的。我曾经相当纠结“信息化”和“数字化”的概念区别，一度认为二者区别是：信息化代表后台系统、围绕业务流程管理；数字化代表以移动APP为特点的数字化产品、围绕用户体验，Gartner的“双模式IT”也恰好有类似的定义。正如90年代末，我刚进入这个行业时，也曾经努力澄清“电算化”和“信息化”的区别。
可以参照行业标准化机构Open Group对“数字化”几个相关概念的定义：
数字技术（Digital Technology）
IT in the form of a product or service that is digitally consumable to create or enable business value.
翻译成中文是：“信息技术（IT）以可被数码化形式消费的产品或服务的形式呈现，从而创造或赋能业务价值”。
所以，DT和IT是有概念区别，如果用最通俗、形象的方式解释，我认为DT，只有两种消耗呈现方式：移动应用、物联网。
数字化（Digitalization）
The application of digital technology to create additional business value within the primary value chain of enterprises.
翻译成中文是：“在企业主要的价值链里，应用数字化技术（DT）创造新增的商业价值”
数字化（Digitization）
The conversion of analog information into digital form.
翻译成中文是：“将模拟信息转化为数字的形式”。
上面两个不同英文字，实在是没法准确地用相应的中文词来表达，只有都叫“数字化”。显然下面这个“数字化”是上面那个“数字化”的基础，是构成商业或组织的“数字化孪生”的基础，只有先“数字化B”了，才能“数字化A”，我一些早期文章思考过这个命题：
数字化转型（Digital Transformation）
The radical, fundamental change towards becoming a digital enterprise.
朝着数字化的企业，彻底的、根本的变化。
直到去年中读了现代企业信息化领域一代宗师Tom Siebel新书《数字化转型》，我才彻底放下纠结。Tom是真正的践行者，他说的，我信。
Tom Siebel并没有刻意将数字技术（DT）和过去30年的企业数据库技术、ERP/CRM等信息技术（IT）应用划清界限，从他的描述来看，数据库和ERP等IT应用是企业数字化的早期阶段，最近几年兴起的营销技术，实乃企业的市场营销部门，是继财务、人事、销售、运营、研发等部门后，最后一个被数字化的部门。而“数字化转型”是指传统企业驾驭云计算、大数据、物联网、人工智能这四大驱动力，而产生的自身进化。
互联网公司是真正的“原生数字化企业”，例如Amazon、谷歌、阿里、腾讯，而传统企业的“数字化转型”，则是指传统企业怎样变成互联网公司的运作方式；数字化转型的终极目标是重构商业、重构行业。见我旧文：
例如：互联、电能的无人驾驶汽车，仅仅是因为采用了不同的汽车驱动技术而颠覆了传统汽车行业吗？在传统汽车之外，能源行业显然是将被颠覆的，不仅如此——警察行业可能也要转型，因为不再有抓醉驾的机会了；保险行业也将被颠覆，今天车辆相关保险占到财产险行业保费收入的60%，互联、无人驾驶的汽车，还会有盗抢险、责任险吗？
所以，今天当企业说起“数字化转型”时，应该是以下三层意思中的一个意思或者几个意思的综合：
传统意义上的数字化转型，和“信息化”并没有太本质的区别
技术意义上的数字化转型，指的是企业信息技术（IT）的架构向数字技术（DT）的架构转化，也叫“架构现代化”（architecture modernization）或者“下一代架构”（next-generation architecture），在新的架构下：
因为使用了移动应用，用户界面更人性化
因为使用了云和新的开发方式，软件部署和更新迭代更快
因为使用了大数据技术，数据分析更实时、更智能。
终极意义的数字化转型，实质上不是技术问题，而是商业战略问题。
过去这几年，在跟企业领导探讨“数字化转型”中，我感觉真正具有第三层思维的企业领导并不多，不少企业领导迷失在社会上一片“数字化转型”的嘈杂中，感到不安甚至恐惧，觉得不转不行。借用一个著名的比喻：数字化转型，就像是毛头小伙子谈性爱：每个人讲得都头头是道，没有人知道真的怎么干；每个人都以为其他人都正在干，也就声称自己也正干着呢。
以上第三层面是纯业务战略问题，已经无关本系列文章“IT规划”的主旨。我们聚焦讨论前面两个层面，第一个层面的规划方法跟我前面两篇文章所介绍的方法并没有变化，我们来看看第二个层面对“IT规划”产生的方法论演化吧。
和过去相比，数字化时代的信息技术规划有三个重要特点：
一，企业级的技术架构转化
上篇文章介绍了“企业架构”方法，业务决定技术的道理并没变，只是随着技术的发展，DT和IT在技术架构上发生了很大变化，见旧文：
从规划框架来看，数字技术产生了很多时髦的概念，例如最近火得烂了大街的“中台”，包括“数据中台”（就是指数据分析平台）、“技术中台”（就是指企业级PaaS）和业务中台（就是指业务微服务）等，也算是新一代架构理论的一个流派。我过去关于中台的文章见：
数字化落地的四个核心问题 | 自建决策，摩登架构，中台赋能和重塑人才
前段时间有位企业领导给我发微信，请我写写以SAP为代表的稳态系统与中台架构的敏态系统的关系，有什么区别，不同行业里应用有啥特点。
传统的信息系统，例如ERP和其他核心系统，跟新一代数字化平台之间的关系，在上面这个规划框架图中展现得很清楚。他们是“后台”系统，或者属于Gartner所说的记录系统（system of records），或称“稳态系统”，和以移动APP为特点的敏态应用区别如下：
敏态系统 | 稳态系统 | |
业务领域 | 业务操作，数据分析，电商及用户互动，员工协作以及其他非关键的企业活动 | 管理系统，例如ERP，CRM，HCM；或者核心业务系统，例如制造执行系统、核心银行系统等 |
服务对象 | 面向操作用户； 面向外部顾客 | 由业务人员操作，最终服务于管理人员 |
应用价值诉求 | 用户体验 | 业务流程 |
数据特点 | 不持续保存，精确度要求不高 | 持续保存，一致性、精确性、合规性要求高 |
系统生命周期 | 生命周期短 | 生命周期长 |
版本迭代 | 快，持续发布新功能和新版本 | 慢，一般以年为单位 |
投入 | 单一系统投入很低，无需复杂实施 | 单一系统投入高，实施复杂 |
技术特点 | 基于公有云的快速开发和部署；基于“平台”的微服务架构 | 单体应用，应用系统内部紧耦合，对外通过服务连接 |
开发和实施方法 | 自研 | 通常采用套装软件，也可以自研 |
需要说明的是，云、大数据和人工智能三者的发展，使得上篇文章提到的郭士纳画的那个企业IT服务栈（Stack）构成发生了很大变化。以DDP的数据层为例（也就是所谓“数据中台”），当前，技术堆栈较为复杂，供应商也很分散，企业需要做大量的整合、开发工作。最近这几年，我给企业做“数字化规划”或者“中台规划”咨询时，不可避免地都会遇到“技术堆栈”选型问题。Tom Siebel的描述如下：
来源：Tom Siebel - 数字化转型，2019
我也一致持有这样的观点，搞“中台”意味着自研产品，需要大量的专业技术人员，短期来看，只有纯技术公司或者大型企业具备这样的能力；长远来看，也许所有的企业都是科技企业。
Tom Siebel在新著中以在AWS上，搭建一个基本的基于AI的预防性维修应用为例，在数据接入和转化、数据湖、数据分析、机器学习、服务交付等模块上需要架构起AWS的若干服务，这就是架构师要干的事情。我认为，早期的“IT规划顾问”今天应该也应该是“云解决方案架构师”（Cloud solution architect）。而基于这样的架构，开发量也是非常巨大，集成也非常复杂：
来源：Tom Siebel - 数字化转型，2019
Tom Siebel目前正在带领创业一家基于物联网的人工智能套件公司，就像30年前开箱即用、无需自己开发的ERP、CRM套件一样，今天，人工智能和物联网也应该提供基于业务模型驱动，业务用户无需考虑内部技术组件构成的“套件”。
他认为，当年企业信息化最大的敌人，是啥都想自己开发的企业CIO；到数字化时代，承担复杂架构和开发管理的CTO角色也越来越重要，Tom下图勾勒的套装企业级AI平台概念：基于多云管理，灵活调动各种基础云服务，支持各种标准SaaS和企业定制软件，应该是一个包含了各种AI能力和功能，提供集成开发环境和微服务的PaaS平台（亦即“中台”）。
来源：Tom Siebel - 数字化转型，2019
二，企业级的数字化产品创造
数字化时代，除了企业级架构转型，即IT基础设施简化、搭建数字化平台外，另一个特点就是在平台上不断创造用户体验导向的数字化产品。数字化产品创造的方法和传统系统开发及实施具有显著区别，即所谓瀑布式和敏捷式的差别，不再是自上而下（业务流程管理，亦即管理需要，以流程管理为核心的）的推导式，而是自下而上（用户直觉式使用的，满足用户的人性化需求，以体验为核心的）的探索式。从这个意义上去理解，“规划”这个词本身就带着自上而下的含义，在数字化时代，这个含义本身就已经被大量消解。
针对数字化产品的规划，涉及到三个重要的方法：1、设计思维，2、用户旅程，3、产品创造及架构。
企业级设计思维方法解决的问题是：
理解用户：深入理解用户的动机、需求和挫败感，使得产品能够激发用户愉悦
定义最小可用产品（MVP）：针对目标画像的人群，提供基本功能，为后续的持续迭代打下基础
协同开发团队：在开发过程中，从相关干系人和目标用户中持续获得反馈，将反馈记录下来，每次迭代解决优先级最高的问题
来源：IBM车库方法手册，2019年，可以在IBM官网下载
联系客服
