浅谈数字化转型的8点思考

引⾔

上周发表了⼀篇《站在甲⽅视⾓，浅谈⼯业互联⽹平台那点事⼉》，结果收到了来⾃圈内各位前辈、良师益友的私信、朋友圈转发和点评，阅读量近3000，第⼀次发⽂，收到这么多的点评，真是蛮感动的。有⼈觉得观点挺好的，视⾓独特，读完之后很受启发；也有⼈观点过于偏激，有点负能量；也有⼈私信我说，那你是不是也可以站在甲⽅视⾓，说说咱们⼯业互联⽹时代到底需要什么呢？那么今天，站在甲⽅视⾓，简单和⼤家⼀起来聊聊⼯业互联时代，企业数字化转型的8点思考。1、匹配能⼒模型的⽬标设定

很多企业的领导，尤其是偏业务部门的领导，说要搞数字化转型，便让HR在市场上⾼薪招聘⼀个智能制造总监，然后就说⼲吧。数字化转型不是⼀个⼈两个⼈能搞起来的，企业在确定要搞数字化转型，在制定数字化转型战略⽬标的时候，⼀定不能忘记的事，要进⾏CapabilityStudy，如果只管⽬标制定，不对能⼒进⾏匹配分析，结果往往⽬标可能⽆法落地。

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

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

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

规模稍⼤，⼈数10⼈以上，除包含规模中的能⼒外，还包含部分数据研究分析能⼒，能够针对特定场景的核⼼过程数据，能够进⾏分析，并总结、提炼，配合供应商进⾏模型研究。2、整体规划的重要性

其实智能制造和数字化转型没有统⼀的标准，做的多也不代表你就是智能制造，做的少也不代表你就不是，智能制造和数字化转型其实就是要解决企业的痛点，如果通过新⼀代信息技术赋能企业业务痛点问题的解决，狭义的来讲，你的项⽬就是智能制造项⽬，没有必要去上⾃⼰不需要的东西，这⾥特别强调⼀点，没有必要为了新技术⽽上技术，新技术⼀定是解决某个问题的。

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

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

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

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

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

3、加强业务和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计较，各有各的绩效考核管理线。项⽬做的好，双⽅都可以得到褒奖。4、精选产品供应商组合策略数字化转型涉及的业务⾯⾮常⼴，要落实企业基于⼀个流的执⾏，很多企业都实施了⼏⼗个，上百个不同的IT系统。表⾯上看呢，感觉信息化做的很成功的，但仔细⼀分析，很多系统都是靠着兄弟们的⾎汗在⼈⾁运维才可以⽀撑下去。⼀般业务在做业务架构规划时，是基于企业的价值链流程来识别业务需求，所以作为甲⽅数字化转型相关的规划团队，除了⽇常要不断积累业务经验，也不要忘记去多⾛出去，了解和对标⾏业内标杆企业和标杆⼄⽅解决⽅案，有能⼒去识别、判定和积累，形成符合企业潜在需求的知识库，以便在项⽬真正来临的时候，不⾄于盲⼈摸象，不知所措。拿汽车⾏业来说，有⼈说选择⼤品牌肯定是不会错的，我都选西门⼦、我都选SAP，或者我都选达索，仔细研究过的⼩伙伴们会发现，其实这些⼤公司，他们虽然产品链很⼴，但并不是每⼀个产品都是你所在的⾏业的最佳解决⽅案，对⼄⽅⽽⾔，他们肯定想卖全套解决解决⽅案，卖点很简单，同⼀家产品，容易整合，但知道内情的⼩伙伴也了解，其实很多软件也是他们买回来后再整合的，整合的⼒度是否真的好，也是有疑问的。所以，如何选择供应商组合策略，这个⼯作⼄⽅⼀般给不了，只有靠甲⽅⾃⼰，通过时间和实践不断去摸索和总结、提炼，因为即使起⼀个咨询项⽬，偏产品解决⽅案的供应商他们带有产品倾向性，不带产品解决⽅案的供应商往往⼜太理论，对具体的产品应⽤可能缺乏实践。图1：基于全价值链供应商组合策略sample5、细分产品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，⼀⽅⾯这些数据量不是特别多，⽽且数据基本都较为保密，另外⼀⽅⾯，这些数据往往都来源于上下游各个应⽤系统，甲⽅主导来协调各⽅⾯资源、推动起来会⽐⼄⽅更容易⼀些，运营数据管理本⾝也没有特别⼤的技术难度。6、变⾰甲⼄双⽅合作模式

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

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

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

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

数字化转型时期，⼀种新的甲⼄合作模式可能会更加适应这种快速迭代、灵活和多变性：甲⽅负责整体规划和项⽬管理，甲⽅根据内部⼈⼒能⼒缺⼝，定义各种外部资源不同组合的能⼒模型需求，⽐⽅说，⽅案顾问、实施顾问、开发顾问、测试顾问等等，根据不同能⼒需求去⼄⽅挑选不同的⼈来⽀持这个项⽬，能⼒要求⾼的可以去原⼚商挑，能⼒要求弱些的可以去原⼚商的代理商挑，这样⼄⽅不在是卖项⽬的交付，是卖能⼒和知识的交付，甲⽅也不是甩⼿掌柜了，甲⽅要真正承担起项⽬最终交付质量的职责和义务。这种做法可以为企业节省很多成本，我之前管理的⼀个项⽬群，就是按照这个模式来运作的，少说会公司节省⼩⼏百万的投资。甲⽅要真正能朝着这个合作模式⾛，有个必要的条件要满⾜：甲⽅内部有这⽅⾯有规划能⼒、综合项⽬管理能⼒的⼈；甲⽅可以和相关潜在合作供应商签署战略⼈天合作框架协议；⼄⽅也愿意配合甲⽅这种⼈天合作模式。7、重视上线运营管理策略

偏强业务管理类的系统，如PLM、ERP、MES，传统的桌⾯运维helpdesk是运维不了的，我们所说的运营，不是只是保证服务器不宕机，那个是狭义的运维，不是运营，系统运营的概念，⾸先得了解和熟悉这个系统内落地实施的流程，在⽤户不清楚或者不懂的情况下，具备培训和引导的职责，同时对系统运⾏的数据可进⾏配置、运⾏状态进⾏分析和提出优化改善建议。⼀个系统或者项⽬上线，只是万⾥长征迈开了第⼀步，其实真正的挑战和困难是运营不是上线。为什么现在很多企业的信息化项⽬上了很多，但反馈都是⽤的不好呢，这有很多原因造成的：

很多软件不是为企业的业务量⾝定做的，项⽬实施过程期间，真正的⽤户往往参与的时间很短，⼀般就需求调研阶段和⽤户接受测试UAT（User Acceptance Test）阶段，加起来估计也不⾜半个⽉，⽽且好多业务关键⽤户在这个参与其间，⼜不是全职，还有很多本职的⼯作，所以在这个阶段，想让最终使⽤的⽤户能对系统功能和体验做出很恰当判定是不可能的；

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

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

软件系统的笨重和复杂，若没有⾜够的运营⽀持和不断的培训推⼴，很多⽤户就放弃使⽤了。那如何制定合适的运营策略呢？

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

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

制定系统⽤户推⼴机制，包含培训、⽇常问题对接处理响应机制。8、不忘前沿领域技术的研究储备

如果说第1～第7点都是脚踏实地，那第8点算是锦上添花。新技术的诞⽣到商业化的应⽤，⼀般都有⼀个很长的时间差。对于传统制造业来说，这个时间差可能会更长。有⼈说，针对新技术的应⽤，传统制造业要⽐互联⽹⾏业⾄少落后5～10年。那作为制造企业的数字化转型团队，如何做到既保障内部稳定，⼜不落后于⾏业的先⾏者们呢？

参观对标交流，通过学习别⼈的案例，了解前沿技术的储备和应⽤情况，这个也是最简单最直接的⽅式，通过看和听来了解；

尝试和⼀些具有代表性的企业展开⼀些合作研究，⽐⽅说AI算法如何应⽤于⼯艺过程质量预防；

经济条件允许的企业，可以内部设置⼀些先机技术研究实验室，可以联合⾼效、企业展开联合创新项⽬，真正落实产学研⼀体化融合，让⾼等学府的孩⼦们能够尽早了解企业的需求，同时也贡献他们在联合研究项⽬的技术能⼒。总结

数字化转型是⼀个复杂的体系化⼯程，对于甲⽅内部来说，要有真正胜任的⼈来牵头，整合内部资源和外部资源，形成真正的数字化转型⽣态圈或者联盟，让合作更加融合，让模式变的更加多元化。数字化转型不是⼀朝⼀⼣的事情，作为企业数字化转型的牵头⼈，要能深刻认识到，数字化转型的成效不在于项⽬过程，⽽在于持续的精益的改善和运营管理。