企业数字化转型的8点思考！

来源：CIO发展中心

全文共5456个字，建议阅读 12 分钟

PART1

匹配能力模型的目标设定

很多企业的领导，尤其是偏业务部门的领导，说要搞数字化转型，便让HR在市场上高薪招聘一个智能制造总监，然后就说干吧。

数字化转型不是一个人两个人能搞起来的，企业在确定要搞数字化转型，在制定数字化转型战略目标的时候，一定不能忘记的事，要进行Capability Study，如果只管目标制定，不对能力进行匹配分析，结果往往目标可能无法落地。

关于数字化转型能力建设，行业内有一种做法，我个人觉得还是蛮可行的，即在业务部门搭建数字化转型团队来牵头企业数字化转型整体规划，该团队直接汇报给负责企业数字化转型的VP。

业务部门牵头推动数字转型，常规的组织能力规模可分为3类：

规模小，一般2～3人，负责与管理层、各业务部门对接，整合和落实管理层业务战略愿景，并推动具体业务部门和IT执行落地；

规模中，一般7～8人，包含各具体业务领域知识的专家，如懂供应链、工艺开发、生产运营、设备标准、前沿先进技术、质量管理细分领域的；

规模稍大，人数10人以上，除包含规模中的能力外，还包含部分数据研究分析能力，能够针对特定场景的核心过程数据，能够进行分析，并总结、提炼，配合供应商进行模型研究。

PART2

整体规划的重要性

其实智能制造和数字化转型没有统一的标准，做的多也不代表你就是智能制造，做的少也不代表你就不是，智能制造和数字化转型其实就是要解决企业的痛点。

如果通过新一代信息技术赋能企业业务痛点问题的解决，狭义的来讲，你的项目就是智能制造项目，没有必要去上自己不需要的东西，这里特别强调一点，没有必要为了新技术而新技术，新技术一定是伴随着解决某个具体问题的，如5G，是解决带宽、延迟还是其他什么现有网络面临的痛点。

整体规划其实在做一件事情，即定义清楚在什么时候需要解决什么问题，锁定的是两个维度属性，时间维度和需求维度。

那为什么整体规划这么重要呢？

整体规划能够让管理层看到未来2～3年的整体蓝图，更容易界定这个标的是不是与他对企业或者战略发展方向的定位是相吻合的，管理层的认同对于后续下面执行层的推动是非常有利的，行业有一种说法叫“所谓领导重视的项目一般都比较好推”；

有了清晰的整体规划，更好识别促成整体规划可落地的相关资源要素的匹配，如预算、人才等；

整体规划也是对企业现状的一种最好的摸底，虽然说规划要仰望星空、对标一流，但我们不能忽视规划最最重要的属性，即立足于企业当下和实际。

通过整体规划的行动，识别出企业当下面临的困难和业务痛点，有时候我们会说，整体规划也是一种持续改善；

如果没有整体规划，很容易被乙方的顾问给”带偏了“。

乙方一般的策略是买解决方案附带卖产品，站在乙方的视角，我也非常能理解，他们需要尽可能把自家的产品卖给客户，卖的越好，业绩就会越好。

很少有乙方在讲解决方案的时候，对用户的现状进行全局分析的，如甲方已经有什么，哪些地方做的好，哪些地方做的不好，我的解决方案是否真的能够给甲方带来价值提升，我卖的解决方案对甲方来说是must，还是nice to have？

细心的小伙伴可能会发现，很多顾问在甲方讲解决方案的时候，都是一个劲的在讲，我有什么，我有什么，估计有90%的时间都在讲我有什么，很少有顾问愿意用50%的时间来分析你需要什么，然后再用50%的时间来讲我有什么。

PART3

加强业务和IT的深度融合

提到两化融合，工业化和信息化的融合，大家都不陌生，站在甲方的视角，真正落实两化融合，首先最应该做的，在管理模式上要落实业务部门和IT部门的融合。

业务融合这个概念很多年前就有人提，提这些概念的人希望传统IT的从业者，能够更加主动地、积极地多了解业务、多深入业务、还有人说业务融合的最高目标是IT人要比业务更懂业务。

制造企业和互联网企业不同，互联网企业，一个211/985计算机专业毕业的应届生，一般3个月到半年时间就可以在Team内独立的工作，3年内，悟性不错的人，基本就可以晋升为Team Leader，独当一面带团队。

相比互联网行业，制造业的流程和体系更为复杂，我身边认识一些985名校毕业的研究生，一些工作2年以上，也只能做些点状的事情。

经常会有朋友问，数字化转型谁牵头会更合适。

我个人不成熟的观点是，业务架构（我要什么）由业务规划团队牵头规划、技术架构（我怎么实现）由IT团队牵头规划，基于3点考虑：

①业务架构更多体现业务管理层对于部门业务中长期的发展战略定位和业务部门运作流程，业务比IT更了解业务，更重要的一点，相比IT，业务规划团队有独特的优势，他们有更多的机会和管理层进一起开会、访谈交流，他们更懂管理层的心声；

②技术架构更偏向底层技术，IT会比业务更懂，知道如何进行资源部署配置，实现性能最优，如使用5G还是wifi，部署私有云还是公有云等；

③IT要和业务保持密切的协作，构建管理Council机制，IT人员前期可以参与业务架构规划的讨论和交流中，从技术层面，给业务人员提供技术指导，便于业务架构最终可实施的可能性。

业务和IT深度融合的过程中，有一点稍微提一下，可能有些企业在推这种模式中面临的问题，功劳属于谁。

业务和IT的深度融合，要求双方团队都要保持开放、包容的心态，因为这种合作模式和传统的业务只提需求，IT全权负责的模式可能有些不同，这种模式前期业务主导，后期IT主导。

所以关于谁的功劳更大，其实这个问题本身也不是问题，毕竟IT汇报给IT线，业务汇报给业务线，本身也不是一条线汇报，IT不必和业务计较，业务也不必和IT计较，各有各的绩效考核管理线。

项目做的好，双方都可以得到褒奖。

PART4

精选产品供应商组合策略

数字化转型涉及的业务面非常广，要落实企业基于一个流程的执行，很多企业都实施了几十个，上百个不同的IT系统。表面上看呢，感觉信息化做的很成功的，但仔细一分析，很多系统都是靠着兄弟们的血汗在人肉运维才可以支撑下去。

一般业务在做业务架构规划时，是基于企业的价值链流程来识别业务需求，所以作为甲方数字化转型相关的规划团队，除了日常要不断积累业务经验，也不要忘记去多走出去，了解和对标行业内标杆企业和标杆乙方解决方案，有能力去识别、判定和积累，形成符合企业潜在需求的知识库，以便在项目真正来临的时候，不至于盲人摸象，不知所措。

拿汽车行业来说，有人说选择大品牌肯定是不会错的，我都选西门子、我都选SAP，或者我都选达索，仔细研究过的小伙伴们会发现，其实这些大公司，他们虽然产品链很广，但并不是每一个产品都是你所在的行业的最佳解决方案。

对乙方而言，他们肯定想卖全套解决方案，卖点很简单，同一家产品，容易整合，但知道内情的小伙伴也了解，其实很多软件也是他们买回来后再整合的，整合的力度是否真的好，也是有疑问的。

所以，如何选择供应商组合策略，这个工作乙方一般给不了，只有靠甲方自己，通过时间和实践不断去摸索和总结、提炼，因为即使一个咨询项目，偏产品解决方案的供应商他们带有产品倾向性，那些纯咨询公司往往又偏向顶层战略、流程规划。

目前，针对这个情况，若甲方真的不具备能力做规划，一种可行的办法是找行业内口碑不错的，第三方监理机构，他们可能更加中立。

PART5

细分产品Make / Buy开发策略

构成数字化转型的系统，主要有两类，一类是自主开发Make，一类是采购Buy，在工业互联网时代，伴随着开源软件、敏捷开发、用户体验、透明运营管理、数据分析等需求越来越多，Make的需求也变的越来越多，那我们在前期规划时，哪些系统适合采购商业化套件，哪些适合自主独立开发呢，才能形成比较完善的开发迭代模式？

偏向工业知识know how多的，这类的软件都比较适合Buy，如PLM、仿真软件、SAP、MES等。

如果选择自主开发，一方面周期长，另一方面，这些系统的底层数据模型非常复杂，没有对业务非常精通的架构师，开发出来的系统，后期对业务可持续拓展的能力是非常薄弱的；

传统工业软件的轻量化适合Make，比方说PLM软件的很多loading、UI界面、各种用户交付的data reports等。

SAP系统的生产计划和MRP，我个人觉得这些国外的工业软件最大的优势是底层的data model的规划，最大的缺点是笨重，开发了很多用户不需要的功能，显得非常笨重，用户体验不好，随着带来的问题就是性能慢。

面向终端用户2C的，如果甲方IT开发能力比较强，可以选择Make，因为这块业务是最能彰显企业对于用户体验和个性化需求的追求；

面向企业运营管理的，一般建议Make。

一方面这些数据量不是特别多，而且数据基本都较为保密。

另外一方面，这些数据往往都来源于上下游各个应用系统，甲方主导来协调各方面资源、推动起来会比乙方更容易一些，运营数据管理本身也没有特别大的技术难度。

PART6

变革甲乙双方合作模式

甲方乙方的合作模式乙方有两种，固定总价合同fixed price和人天合同T&M，以前很多企业的信息化项目都比较倾向于选择fixed price，这个对甲方来说，简单而且风险低，交付的质量和过程管控的压力都丢给了供应商，fixed price合同不好的地方是什么呢？

耗费周期长，因为固定总价，所以潜在甲乙双方在准备SOW的时候，字字斟酌，乙方担心前期若范围不谈清楚，后期范围的变更承受不了；

灵活性差，偏管理类的信息化项目，即使前期规划的很多，但是在具体实施过程中，还是会存在很多需求的变更和调整，针对fixed price的合同，后期的每次需求变更都需要反复和乙方扯皮；

不可持续，fixed price合同一般都有固定的项目结束周期，项目上线交付后，乙方通过验收，基本就撤离了，交给甲方来运营管理，很多企业的甲方一方面可能没有能力、另外一方面可能也不是很重视运营，导致很多上线的项目和系统，半年后，就黄了，很少有人用。

数字化转型时期，一种新的甲乙合作模式可能会更加适应这种快速迭代、灵活和多变性：

甲方负责整体规划和项目管理，甲方根据内部人力资源缺口，重点是资源能力缺口，定义各种外部资源不同组合的能力模型需求，比方说，方案顾问、实施顾问、开发顾问、测试顾问等。

根据不同能力需求去乙方挑选不同的人来支持这个项目，能力要求高的可以去原厂商挑，能力要求弱些的可以去原厂商的代理商挑。

这样乙方不在是卖项目的交付，是卖能力和知识的交付，甲方也不是甩手掌柜了，甲方要真正承担起项目最终交付质量的职责和义务。

这种做法可以为企业节省很多成本，我之前管理的一个项目群，就是按照这个模式来运作的，少说会公司节省小几百万的投资。

甲方要真正能朝着这个合作模式走，有3个必要的条件要满足：

甲方内部有这方面有规划能力、综合项目管理能力的人；

甲方可以和相关潜在合作供应商签署战略人天合作框架协议；。

乙方也愿意配合甲方这种人天合作模式。

PART7

重视上线运营管理策略

偏强业务管理类的系统，如PLM、ERP、MES，传统的桌面运维helpdesk是运维不了的，我们所说的运营，不是只是保证服务器不宕机，那个是狭义的运维，不是运营，系统运营的概念，首先得了解和熟悉这个系统内落地实施的流程，在用户不清楚或者不懂的情况下，具备培训和引导的职责，同时对系统运行的数据可进行配置、运行状态进行分析和提出优化改善建议。

一个系统或者项目上线，只是万里长征迈开了第一步，其实真正的挑战和困难是运营不是上线。为什么现在很多企业的信息化项目上了很多，但反馈都是用的不好呢，这有很多原因造成的：

很多软件不是为企业的业务量身定做的，项目实施过程期间，真正的用户往往参与的时间很短。

一般就需求调研阶段和用户接受测试UAT（User Acceptance Test）阶段，加起来估计也不足半个月，而且好多业务关键用户在这个参与其间，又不是全职，还有很多本职的工作。

所以在这个阶段，想让最终使用的用户能对系统功能和体验做出很恰当判定是不可能的；

项目功能测试的数据也是伪造的，UAT测试不可能把所有的业务流程都能按照1：1实物流程运作一遍，这个时候的测试往往并不能识别很多潜在的问题；

业务的需求在不断的变化，很多业务本身也是在不断通过项目不断优化和完善，因此不可能基于半年前或者一年前提的需求，还能那么好的兼容；

软件系统的笨重和复杂，若没有足够的运营支持和不断的培训推广，很多用户就放弃使用了。

那如何制定合适的运营策略呢？

系统IT系统运维策略，保证系统的运行稳定性、可靠性和性能；

制定业务数据运营，针对系统内的业务数据质量和流程，根据实际用户的使用情况，定期分析和评估判定，识别出影响系统应用的潜在问题和风险，并和规划团队进行沟通，制定改善策略；

制定系统用户推广机制，包含培训、日常问题对接处理响应机制。

PART8