制造企业数字化转型的思考

咸向明

匹配能力模型的目标设定

很多企业的领导，尤其是偏业务部门的领导，说要数字化转型，便让HR在市场上高薪招聘智能制造总监，但数字化转型不是1～2个人能做起来的，企业在确定要做数字化转型，在制定数字化转型战略目标时，一定不能忘记进行Capability Study，如果只管目标制定，不对能力进行匹配分析，结果往往是目标可能无法落地。

关于数字化转型能力建设，行业内有一种做法，即在业务部门搭建数字化转型团队来牵头企业数字化转型的整体规划，该团队直接汇报给负责企业数字化转型的VP。业务部门牵头推动数字转型，常规的组织能力规模可分为3类：

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

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

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

整体规划的重要性

其实智能制造和数字化转型没有统一的标准，做的多也不代表就是智能制造，做的少也不代表就不是，智能制造和数字化转型其实就是要解决企业的痛点。如果通过新一代信息技术赋能企业业务痛点问题，狭义的来讲，就是智能制造项目，没有必要上自己不需要的东西。这里特别强调一点，没有必要为了新技术而新技术，新技术一定是伴随着解决某个具体问题的，如5G，是解决带宽、延迟或其他现有网络面临的痛点。

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

因为整体规划能够让管理层看到未来2～3年的整体蓝图，更容易界定这个标的是不是与他对企业或者战略发展方向吻合，管理层的认同对于后续下面执行层的推动非常有利，行业有一种说法叫“领导重视的项目一般都比较好推”。有了清晰的整体规划，才能更好识别促成整体规划可落地的相关资源要素，如预算、人才等。

整体规划也是对企业现状的一种最好的摸底，虽然说规划要仰望星空、对标一流，但我们不能忽视规划最最重要的属性，即立足于企业当下和实际。通过整体规划的行动，识别出企业当下面临的困难和业务痛点，有时候我们会说，整体规划也是一种持续改善。

如果没有整体规划，很容易被乙方的顾问给”带偏了“。乙方一般的策略是买解决方案附带卖产品，站在乙方的视角也非常能理解，他们需要尽可能把自家的产品卖给客户，卖的越好，业绩就会越好。很少有乙方在讲解决方案的时候，对用户的现状进行全局分析的，如甲方已经有什么，哪些地方做的好，哪些地方做的不好，我的解决方案是否真的能够给甲方带来价值提升，我卖的解决方案对甲方来说是must，还是nice to have？细心的小伙伴可能会发现，很多顾问在甲方讲解决方案的时候，都是一个劲的在讲，我有什么，估计有90 %的时间都在讲我有什么，很少有顾问愿意用50 %的时间来分析你需要什么，然后再用50 %的时间来讲我有什么。

加强业务和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系统。表面上看，感觉信息化做的很成功的，但仔细分析，很多系统都是靠着兄弟们的血汗“人肉”运维才可以支撑下去。

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

拿汽车行业来说，有人说选择大品牌肯定不会错，例如西门子、SAP、达索，仔细研究过的小伙伴会发现，其实这些大公司虽然产品链很广，但并不是每一个产品都是你所在行业的优秀解决方案。对乙方而言，他们肯定想卖全套解决方案，卖点很简单，同一家产品容易整合，但知道内情的小伙伴也了解，其实很多软件也是他们买回来后再整合的，整合的力度是否合适也是有疑问的。所以，如何选择供应商组合策略，这个工作乙方一般给不了，只有靠甲方自己，通过时间和实践不断摸索和总结、提炼，因为即使一个咨询项目，偏产品解决方案的供应商也带有产品倾向性，那些纯咨询公司往往又偏向顶层战略、流程规划。目前，针对这个情况，若甲方真的不具备能力做规划，一种可行的办法是找行业内口碑不错的第三方监理机构，他们可能更加中立。

细分产品Make/Buy开发策略

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

偏向工业知识多的，这类的软件都比较适合Buy，如PLM、仿真软件、SAP、MES等，如果选择自主开发，一方面周期长；另一方面，这些系统的底层数据模型非常复杂，没有对业务非常精通的架构师，开发出来的系统，后期对业务可持续拓展的能力非常薄弱。

传统工业软件的轻量化适合Make，比如PLM软件的loading、UI界面、用户data reports等，SAP系统的生产计划和MRP，个人觉得这些国外的工业软件最大的优势是底层的数据模型的规划，最大的缺点是笨重，开发了很多用户不需要的功能，用户体验不好，随着会带来性能的问题。

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

面向企业运营管理的，一般建议Make，一方面这些数据量不是特别多，而且数据基本都较为保密。另外一方面，这些数据往往都来源于上下游各个应用系统，甲方主导来协调各方面资源、推动起来会比乙方更容易一些，运营数据管理本身也没有特别大的技术难度。

变革甲乙双方合作模式

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

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

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

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

数字化转型时期，一种新的甲乙合作模式可能会更加适应这种快速迭代、灵活和多变性：甲方负责整体规划和项目管理，甲方根据内部人力资源缺口，重点是资源能力缺口，定义各种外部资源不同组合的能力模型需求。比如，方案顾问、实施顾问、开发顾问、测试顾问等，根据不同能力需求去乙方挑选不同的人来支持这个项目，能力要求高的可以去原厂商挑，能力要求弱些的可以去原厂商的代理商挑。这样乙方不再是卖项目的交付，是卖能力和知识的交付，甲方也不是甩手掌柜了，甲方要真正承担起项目最终交付质量的职责和义务。这种做法可以为企业节省很多成本，本人之前管理的一个项目群，就是按照这个模式来运作的，少说也会公司节省小几百万的投资。

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

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

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

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

重视上线运营管理策略

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

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

很多软件不是为企业的业务量身定做的，项目实施过程期间，真正的用户往往参与的时间很短，一般就需求调研阶段和用户接受测试（UAT）阶段，加起来也不足半个月，而且好多业务关键用户在参与其间不是全职，所以在这个阶段，想让最终使用的用户能对系统功能和体验做出很恰当判定是不可能的；

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

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

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

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

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

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

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

不忘前沿技术的研究储备

如果说前面都是脚踏实地，那最后这点算是锦上添花。新技术的诞生到商业化的应用，一般都有一个很漫长的时间差。对于传统制造业来说，这个时间差可能会更长。有人说，针对新技术的应用，传统制造业要比互联网行业至少落后5～10年。那作为制造企业的数字化转型团队，如何既保障内部稳定，又不落后于行业的先行者们呢？参观、对标、交流，通过学习别人的案例，了解前沿技术的储备和应用情况，这个也是最简单、最直接、最可行的方式，通过看和听来了解。

尝试和一些具有代表性的企业展开一些合作研究，比如AI算法如何应用于工艺过程质量预防。

经济条件允许的企业，可以内部设置一些先进技术研究实验室；可以联合高校、生态圈其他同行建立联合创新项目，真正落实产学研一体化融合，让高等学府的孩子们能够尽早了解企业的需求。

数字化转型是一个复杂的体系化工程，对于甲方来说，要有真正胜任的人来牵头，整合内部资源和外部资源，形成真正的数字化转型生态圈或者联盟，让合作更加融合，让模式更加多元化。

数字化转型不是一朝一夕的事情，要做好打持久战的准备。作为企业数字化转型的牵头人，要能深刻认识到，数字化转型不是一批项目上线就结束了，要始终秉持持续、精益的运营改善思维和理念，在数字化转型过程培养人才，在培养人才过程中促成企业数字化转型升级。