今天总结下我对企业数字化转型的一个重要观点，即对于传统企业的数字化转型，前面谈了很企业商业模式重构，数据驱动，运营驱动，流量思维等，而很少谈到企业IT部门本身应该如何进行数字化转型或具备数字化思维。

而企业IT部门本身也应该进行数字化转型或具备数字化思想。

即企业的CIO应该将企业的IT部门认为是一个独立运作的经营体或IT公司，其输入是企业的市场需求和用户需求，其最终交付的是有价值的软件产品或软件服务。

那么企业的IT部门应该如何进行转型？

还是回到数字化转型的几大核心内容，即连接，数据，智能三个方面进行思考。通过连接解决了协同问题，通过协同产生了数据，通过对数据的分析产生智能。这三大要素是数字化的核心底层逻辑。

其次，我在前面谈数字化思想的时候，谈到数字化的另外一个关键点是解决信息在时间和空间上位移的一致性问题。解决信息由人工输入，人工去核对校准的各种重复录入，不一致等问题，这些同样对于IT部门适用。

当前对于中大型企业在进行数字化转型过程中有几个关键发展趋势，即IT部门更多的是进行软件系统的自主研发，而不再是简单的购买成熟的各种商用套件在进行集成。因此这使得企业IT部门更可以像成熟的软件公司一样进行经营和运作。

包括当前一些大企业本身也将其IT部门单独划拨出来成立独立的软件公司，一个方面是可以享受国家税收方面的优惠政策，更加重要的是软件公司独立经营后本身也可以进一步从原来的成本单元走向利润中心，为其它企业提供同样的软件产品或服务。

连接和协同-软件产品的流水线

软件产品本身的生产和交付遵从软件完整的软件生命周期。从最开始的市场需求或用户需求，到软件需求分析和开发，再到设计和编码，最终测试完成交付上线，用户验证确认后形成完整的闭环流程。

因此最长的端到端是从用户驱动开始的需求端到端闭环流程。

对于大部分IT部门来讲实际没有形成完整的从业务部门提出用户需求到最终业务部门验证关闭的完整端到端流程管理和跟踪体系。

在这个大流程下，就会到了软件本身生产和交付的关键子流程，这也是我在谈云原生整体解决方面时候经常谈到的DevOps支撑过程，CI/CD持续集成和交付过程。

也就是整个从软件编码开始的，编译，构建，打包，部署，测试等过程形成自动化的流水线执行，既减少人力投入成本，又通过自动化来提升协同效率。

需求端到端管理+自动化CI/CD两者更好地协助IT部门完成连接和协同层面的问题。

而这些内容也正好是我前面文章多次谈到的构建一个完整的覆盖端到端软件生命周期的云原生整体解决方案的一个原因。特别是里面的微服务和DevOps可以更好的去解决连接，协同和自动化，敏捷方面的问题。

度量和持续改进-数据驱动思维

软件产品的生产和交付过程，涉及到需求，设计，编码，开发诸多的岗位角色，通过连接来实现尽可能的自动化，并减少沟通和协同成本。

但是一个好的数字化思维一定是数据驱动的持续改进。形成连接协同后，一定会产生和沉淀数据，需要去应用和分析数据，通过数据驱动来持续对软件生命周期流程进行改进。

在这里首先要谈的又是敏捷和短周期迭代思想。

这个实际和精益生产里面的小批量，多批次的思想很类似。即通过将大的需求进行分解，然后规划到多个短周期的版本进行交付和实现。每个迭代版本都是独立可交付，可验证。通过这种短周期迭代一方面是缩短了交付周期，一方面是快速地完成每一轮迭代，方便分析数据进行复盘，以优化下一次的版本迭代过程。

在最早做CMMI过程改进的时候经常谈到软件度量这个词，度量本身就是软件开发过程中核心的数据驱动思维。

通过度量分析你会发现你的软件开发效率低，质量差究竟是哪些地方出问题了？是客户需求频繁变动，还是关键评审缺失，还是人员技能有问题，还是沟通协同，无效会议浪费了大量时间等，这些本身是需要数据来说话。

数据反哺业务。这个概念拿到软件开发生命周期来说同样适用，即软件开发生命周期过程产生的数据需要时刻关注，通过数据去及时的优化和调整软件开发过程。

举个简单的例子来进行说明，当一个大的需求变更在开发完成后，软件能否自动地帮忙分析完成，并告诉你这个变更可能会对哪些相关功能造成影响，建议你对哪些相关功能进行详细全面的测试和验证。再比如你开发人员编码完成后，系统自动根据你经常犯错的地方进行检查，告诉你哪些地方不符合规范等。

也就是说数据不仅仅是版本完成或阶段性的分析决策，更加重要的是通过数据的分析实时的辅助改进整个软件生产和交付过程。

在前面一篇谈DevOps自动化和持续集成的文章里面，我也专门提出，不是自动化就帮助你彻底解决了工程域本身的问题，工程域的问题解决更多的需要依靠数据度量和分析，需要提升需求开发和架构设计能力，需要提升整个人员技能水平。

即当你看到需求不稳定频繁变动，而且经常需要紧急发布，你的观点不应该是通过CI/CD自动化方式来解决提升发布效率，而是应该考虑如何解决需求频繁变动的问题。

软件本身的智能化

在我前面的文章中也会谈到大数据，BI商业智能，机器学习和AI人工智能的话题，而今天想谈下软件智能。软件智能是我自己提出的一个说法，即指我们开发实现并部署的应用软件本身具备自我适应，自我优化，自我调整能力，即可以称为软件智能。

基础智能是基于输入+预设规则做出的快速决策和判断

在我们谈到云计算PaaS平台的时候，谈得比较多的是软件应用托管，在托管完成后实现软件应用更加业务访问并发量的动态资源扩展和调度能力，这个能力可以做为软件智能的一部分。即软件具备了面向不同的并发场景下自我适应，弹性调度和动态扩展的能力，而这个过程不再需要人工干预。

基于这个场景，我们回来来总结下，实现该智能调度的关键点包括了：

1. 预先定义和配置的资源调度规则和算法

2. 实时的健康相关性能数据采集

3. 基于采集数据动态计算和规则进行匹配，基于结果触发决策行为

具备了以上三点后基本就具备了最基本的动态资源扩展能力，也可以算作为最基本的软件智能能力。

今天我想谈的，或者想展望的是，一个实现完成后的应用软件，是否能够具备在业务功能和需求上面的动态调整，自我适应能力，即在业务场景和业务需求变化下能够完成动态自我调节。

如果要实现这点，需要考虑在软件功能实现的时候，业务规则必须要进行剥离，形成可以灵活定义和配置，包括复合的规则集合。软件实际的行为可以在某种场景和输入下触发的一系列规则的联动和执行。同时对业务输入进行采集和分析，选择最优的规则触发后续行为。

要实现软件的智能关键之一还是业务规则剥离，能够灵活配置。其次就是我们要对各种业务场景下的输入进行分析，建立输入数据和预设规则之间的联动关系，或者说最优联动方式。基于这两者我们就可以基于已有的规则引擎或智能算法选择软件的执行路径并返回结果。

软件智能化的关键之二即是数据驱动思维，即基于整个需求端到端和软件生命周期过程中，包括到后期的运维和APM过程，不论是人工协同还是自动化流水线产生的数据，还是运维阶段收集的性能和日志数据，最终通过数据分析来确定软件应该如何优化和改进。

这种软件智能有很多具体的体现点，我们可以举例来说明下

在一个表单录入的时候，我们发现我们原来预设的表单数据项录入顺序并不是客户实际录入顺序，那么我们的软件是否可以动态的基于用户的使用习惯，对表单录入数据项顺序完成动态调整？

当然我们可以根据用户的使用场景和使用习惯，基于不同的用户给出具体的功能编排和快捷进入，并且对不同功能页面间的连接进行重新编排等。我们也可以根据用户经常使用的查询功能和查询条件等进行分析识别，在用户每次进入的时候给出最优的查询组合等。

软件应用在后台运行中会发现某种业务场景或业务并发下会导致资源出现性能瓶颈问题，那么应用可以自动的分析出现性能问题的原因，并对软件应用代码进行优化和调整。类似软件应用功能中最常见的在基础模型确定情况下，单纯的扩展数据项功能，软件能够完全做到灵活可配置的扩展，而不在需要进行代码级别修改和重新部署发布。

场景的业务规则和逻辑的修改，都可以不修改代码，而是修改我们的规则配置，规则可以做到灵活配置，基于规则来触发最终的事件和后台操作。同时我们可以在软件应用中配置业务场景输入，规则，输出行为三者之间的联动关系，当输入场景变化或规则变化的时候我们只需要对三者进行修改或重新配置即能够满足需求，或者根本都不需要人为进行修改，而是通过软件自适应来完成调整。

理想情况下，一个软件上线完成后基本能够做到不需要运维人员和监控人员，软件出现的问题或故障能够自动的进行分析，在分析后给出自动的解决措施并完成解决，或者给用户最佳的问题处理方式和流程。即在我们传统软件运维监控的基础上，能够进一步做到出现问题也能够被自动修复和解决，而不需要人工干预。如果出现问题，在采用了类似重启等方式进行解决后，也能够对问题产生的根本原因进行深入分析，以对内部实现逻辑和机制进行优化和调整，从根本上避免问题的再次出现。

所以现在一谈数字化转型，谈数据中台和智能化分析，就在谈业务流程和业务数据的分析，而很少谈更加重要的是软件系统本身也应该进行智能化分析，来写作软件本身的优化和改进。如果企业的IT部门都无法实现数字化，无法通过连接-协同-智能来优化自身，那么又如何能够更好地支撑整个企业的数字化。

从软件运维到运营，从运营到服务

当将企业的IT部门作为一个独立的经营体来看待的时候，不仅仅考虑的是其成本收益分析，更加重要的就是整个市场化运作思路的引入，从运维到运营的转变。

传统的IT部门更加强调的是运维，而当前新数字化转型下IT部门更加重要的是技术运营，即不仅仅是保障IT系统线上运行不出现故障，更加重要的是如何通过数据分析，通过运营来让已经构建的IT应用发挥最大的效能，更好的支撑业务运作。

数据中心的各种服务器网络资源，开发完成的软件程序本身是没有价值的，真正有价值的是各种资源最终提供出来的服务能力。服务本身依托于资源之上，但是真正创造价值的是服务，服务创造价值的方式则是支撑业务运作。

企业IT部门可以借鉴互联网SaaS服务开发商的思路，即将IT部门看做是一个面对内部客户需求的软件服务商，其提供的是软件服务，而要做好服务需要的又是基于数据的持续运营。

举个简单的例子，当我们新上线一个功能后，基于运营的思路我们会去分析新上线这个功能究竟使用频率如何，在使用过程中真正带来了哪些服务增值。如果使用过程效率不高，基于采集的数据分析究竟是哪里需要优化改进。

运营的思路一定不是一个功能上线就完事，而是持续跟踪和优化该功能，让该功能创造出最大的价值。企业IT部门如何从传统的运维思路转到运营思路绝对是IT部门数字化转型中的一个关键思维转变。

往期推荐

钛媒体深度

复刻SHEIN，中国跨境供应链大突围

诱人的低代码，未到狂欢时

独家对话阿里云张建锋：云计算接近进入下一个时代

双碳观察

对话百度智能云常城：跟企业谈双碳，还是要讲实际价值

全国碳市场上线一周年：累计成交额80多亿，四大问题待解

数字思考者50人

阿里最懂数据的团队，也出来创业了

制造业研发IT正迎来利好，但问题是什么？

清华大学林常乐：数据要素定价的思考与实践

本周周报速递

▼

往期周报回顾

▼