关于创新:老马闲评数字化4做数字化会不会被供应商拿捏住
原文作者：行云翻新 CEO 马洪喜“老马闲评”系列文章正在“深圳行云翻新”公众号连载，感兴趣的敌人请关注咱们的公众号，不迷路…… 导语开年过后业务特地的忙碌，出差也比拟多，所以有段时间没更新了，对不住大家！ 上一集（您能够查看“行云翻新”主页浏览原文）咱们聊了数字化转型的“想转、急转、不敢转”的企业现状，次要还是有很多放心，比方：到底是业务部门还是技术部门牵头，这就是首当其冲的问题。明天，咱们再聊聊其余方面的担心，就拿“数字化转型是否会被供应商拿捏住”这个事开聊吧。 注释老马我大学毕业就做乙方了，素来没体验过甲方的高兴和苦恼。然而，这么多年我结交了各行各业、国内国外甲方的好敌人，在闲聊中也体验到个中滋味。所以我常常对我的搭档们说，签合同前甲方是牛气，签完合同就不同了。如果乙方搞砸我的项目，最多就是收不了款拍拍屁股做了下一个我的项目，但甲方面临的是烂摊子，当初反对乙方的甲方领导可能因为这个我的项目影响到他的职业生涯。所以，作为乙方要有“如履薄冰”的心态，做“对得起敌人，不辜负信赖的事儿”。 供应商不认真做事还不能算是被其拿捏，最多是当初看走眼，自作自受。那是否有供应商通过高价或是其余的策略进入一期我的项目，想进去后通过二期盈利呢？尽管这对大家都不太好，但目前来看这种景象是有的。不仅公有云有，私有云也蛮多的，给予新客户极大的折扣，来年就复原原价。但我集体认为，尽管不太爽，但思考到更换供应商的老本和对方的确此前付出了很多，只有不是太过分的，大多甲方还是会通过会谈与乙方持续单干，这种也不能算是拿捏。 真正的“拿捏”往往是不受甲乙双方之可控，但对单方特地是甲方影响甚大，我列举以下几个示例。 前一天还一起加班，第二天被告诉离场，我的项目中断。我据说这么一个故事，某甲方公司项目组和某外企供应商的征询团队长期单干，一起加班熬夜上线零碎，一起宵夜烧烤啤酒，都混成兄弟了。忽然间外企的征询团队收到外部邮件，因为该甲方公司被 A 国列入所谓的“实体名单”，所以必须马上进行提供技术服务。可想而知单方我的项目人员都是懵逼的，其对我的项目的影响也是微小的。这种状况能够称之为“黑天鹅式拿捏”。 没有一个是错的，但加在一起有点不对。多供应商参加信息化、数字化建设很广泛，在精细化分工大趋势下，将来将是越来越如此。在传统单干模式下，特地是分不同包离岸开发的场景，不同的乙方都有一套本人的“玩法”。就拿中间件来说，有的用 Kafka, 有的用 RocketMQ，有的用 RabbitMQ，抉择什么中间件、技术框架大多是看乙方架构师、程序员的集体善于或是爱好。各自都没错，但当有这样的若干个我的项目交付给甲方之后，甲方的运维人员是一头包：他们面临 N 多种技术组件的 N 多个版本，监控伎俩、平安伎俩、排错和备份伎俩都不一样。这样的难堪状况能够称之为“群体性拿捏”。 痛点不大但很痛，求人求己皆不能。我有一个客户，他们在制造业也算头部了，很多业务零碎早就建成了，但当初建设的时候都是一个个垂直的烟囱，没有思考到有一天须要一个横向的流程，逾越多个零碎往返交互数据。这个需要还没有大到专门申请一笔估算立项、投标、洽购、项目管理、验收。而且这个痛点的“痛法”恐怕也是独特的，没有供应商轻车熟路，最多就是在泛滥烟囱零碎间再横上个杆子。问题是相似的痛点不止一处，将来还有新的痛法，“治标不治本”的办法只能让事件更简单。这个场面不是任何一个供应商造成的，咱们称之为“自我拿捏”。 后面第二集（您能够查看“行云翻新”主页浏览原文）中提到，数字化转型是“求生路”，实质是靠本人，如果轻易的靠某个供应商的某个业务零碎就数字化胜利了，那就不叫转型了，所以“自主可控、数字化命运把握在本人手中”是数字化转型的外围因素。 后面提到的三个“供应商拿捏”的状况，咱们再剖析一下： · 黑天鹅式拿捏——根因是适度依赖繁多供应商，没了他,我的项目玩不转了。· 群体性拿捏——根因是没有建设一套甲方本人的规范，任由不同供应商各搞各的。· 自我拿捏——无论在流程还是技术上，都短少跨供应商、跨业务零碎的协同能力。 无论哪种状况的防止，都须要甲方有自主可控的数字化建设思维。这种思维体现在意识、治理、组织、流程、技术等多个维度。 金融畛域始终是数字化建设的排头兵，也是国家层面数字化领导政策的风向标。早在去年年初，就有《中国银保监会办公厅对于银行业保险业数字化转型的领导意见》一文，该文高屋建瓴的给出了一些具体的领导意见，老马深表同意，也倡议跨行业的敌人认真的钻研参考一下，这里援用几点具体的意见： · 自主研发——对要害平台、要害组件以及要害信息基础设施要造成自主研发能力，升高内部依赖、防止繁多依赖。 · 研发平台——建设可能疾速响应需要的麻利研发运维体系，踊跃引入研发运维一体化工具，建设企业级一站式研发协同平台。 · 规范模块——次要业务零碎实现平台化、模块化、服务化，增强企业架构设计，实现共性业务性能的标准化、模块化。 · 多活核心——优化数据中心布局，构建多核心、多活架构，进步基础设施资源弹性和继续供应能力。 我了解其外围要义还在是“自主可控”四字上。自主可控相对不是指啥事都本人干了，齐全不依赖于供应商了，这不仅没必要，而且是一种微小的节约，在“术业有专攻”和“越来越精细化”的大背景下，肯定是善于的人做善于的事是对所有人都好。自主可控是解决被供应商拿捏的伎俩，但除了主观上想这样，还有什么方法论或是配套设施能“我的地盘我做主”又能“一个好汉三个帮”？答案就是“（甲方）搭台（多个乙方）唱戏”。先搭好一个台子，不仅仅是意识之台、治理之台、组织之台、流程之台，也是技术之台，而且往往是通过一个技术平台把意识、治理、组织、流程体现进去的。 这个技术平台叫什么？有人叫他技术中台、业务中台，有人叫他 PaaS，咱们行云称之为企业数字化翻新平台。叫什么其实无所谓，要害是有没有践行“搭台唱戏”的准则，是否能让甲方在数字化中“当家作主”，又能组织多个乙方“集思广益”，最终能聚力于数字化转型这个外围指标上。 后记有敌人可能看完会说，这不就是“中台策略”嘛，人家 XXX 都曾经不提中台了，中台是伪命题。首先我想说的，那个 XXX 其实还是提中台的，是中台的拥护者。其实，中台也好，PaaS 也好，搞好这些台子，特地是达到前述成果不太容易，波及到的简单因素蛮多的，数字化转型尽管急切，但也不能“一口吃成个瘦子”。无论抉择什么样的建设思路或是技术路线，究竟还是得钻研透，这个过程中也是须要有供应商一起出谋划策的，而不是“闭门造车”。像行云这样的“见得多点、聊得多点、做得多点”，又长期聚焦于帮忙甲方“搭台唱戏”的团队，我想能帮到您少走点弯路、做些即求实又久远的布局和建设。期待和您交个敌人，一起聊聊数字化转型那些事。 同角度的观点或是乏味的故事，还请您不吝赐教，期待能成为您数字化道路上的敌人。