原文作者：行云创新 CEO 马洪喜

“老马闲评”系列文章正在“深圳行云创新”公众号连载，感兴趣的朋友请关注我们的公众号，不迷路……

导语

开年过后业务特别的繁忙，出差也比较多，所以有段时间没更新了，对不住大家！

上一集（您可以查看“行云创新”主页阅读原文）咱们聊了数字化转型的“想转、急转、不敢转”的企业现状，主要还是有很多担心，比如：到底是业务部门还是技术部门牵头，这就是首当其冲的问题。今天，我们再聊聊其他方面的担忧，就拿“数字化转型是否会被供应商拿捏住”这个事开聊吧。

正文

老马我大学毕业就做乙方了，从来没体验过甲方的快乐和苦恼。但是，这么多年我结交了各行各业、国内国外甲方的好朋友，在闲聊中也体验到个中滋味。所以我经常对我的伙伴们说，签合同前甲方是牛气，签完合同就不同了。如果乙方搞砸项目，最多就是收不了款拍拍屁股做了下一个项目，但甲方面临的是烂摊子，当初支持乙方的甲方领导可能因为这个项目影响到他的职业生涯。所以，作为乙方要有“如履薄冰”的心态，做“对得起朋友，不辜负信任的事儿”。

供应商不认真做事还不能算是被其拿捏，最多是当初看走眼，自食其果。那是否有供应商通过低价或是其他的策略进入一期项目，想进去后通过二期盈利呢？虽然这对大家都不太好，但目前来看这种现象是有的。不仅私有云有，公有云也蛮多的，给予新客户极大的折扣，来年就恢复原价。但我个人认为，虽然不太爽，但考虑到更换供应商的成本和对方确实此前付出了很多，只要不是太过分的，大多甲方还是会通过谈判与乙方继续合作，这种也不能算是拿捏。

真正的“拿捏”往往是不受甲乙双方之可控，但对双方特别是甲方影响甚大，我列举以下几个示例。

前一天还一起加班，第二天被通知离场，项目中断。我听说这么一个故事，某甲方公司项目组和某外企供应商的咨询团队长期合作，一起加班熬夜上线系统，一起宵夜烧烤啤酒，都混成兄弟了。突然间外企的咨询团队收到内部邮件，由于该甲方公司被 A 国列入所谓的“实体名单”，所以必须马上停止提供技术服务。可想而知双方项目人员都是懵逼的，其对项目的影响也是巨大的。这种情况可以称之为“黑天鹅式拿捏”。

没有一个是错的，但加在一起有点不对。多供应商参与信息化、数字化建设很普遍，在精细化分工大趋势下，未来将是越来越如此。在传统合作模式下，特别是分不同包离岸开发的场景，不同的乙方都有一套自己的“玩法”。就拿中间件来说，有的用 Kafka, 有的用 RocketMQ，有的用 RabbitMQ，选择什么中间件、技术框架大多是看乙方架构师、程序员的个人擅长或是喜好。各自都没错，但当有这样的若干个项目交付给甲方之后，甲方的运维人员是一头包：他们面临 N 多种技术组件的 N 多个版本，监控手段、安全手段、排错和备份手段都不一样。这样的尴尬情况可以称之为“群体性拿捏”。

痛点不大但很痛，求人求己皆不能。我有一个客户，他们在制造业也算头部了，很多业务系统早就建成了，但当初建设的时候都是一个个垂直的烟囱，没有考虑到有一天需要一个横向的流程，跨越多个系统往复交互数据。这个需求还没有大到专门申请一笔预算立项、招标、采购、项目管理、验收。而且这个痛点的“痛法”恐怕也是独特的，没有供应商驾轻就熟，最多就是在众多烟囱系统间再横上个杆子。问题是类似的痛点不止一处，未来还有新的痛法，“治标不治本”的方法只能让事情更复杂。这个局面不是任何一个供应商造成的，我们称之为“自我拿捏”。

前面第二集（您可以查看“行云创新”主页阅读原文）中提到，数字化转型是“求活路”，本质是靠自己，如果轻易的靠某个供应商的某个业务系统就数字化成功了，那就不叫转型了，所以“自主可控、数字化命运掌握在自己手中”是数字化转型的核心要素。

前面提到的三个“供应商拿捏”的情况，我们再分析一下：

· 黑天鹅式拿捏——根因是过度依赖单一供应商，没了他,项目玩不转了。

· 群体性拿捏——根因是没有建立一套甲方自己的标准，任由不同供应商各搞各的。

· 自我拿捏——无论在流程还是技术上，都缺少跨供应商、跨业务系统的协同能力。

无论哪种情况的避免，都需要甲方有自主可控的数字化建设思维。这种思维体现在意识、管理、组织、流程、技术等多个维度。

金融领域一直是数字化建设的排头兵，也是国家层面数字化指导政策的风向标。早在去年年初，就有《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》一文，该文高屋建瓴的给出了一些具体的指导意见，老马深表赞同，也建议跨行业的朋友认真的研究参考一下，这里引用几点具体的意见：

· 自主研发——对关键平台、关键组件以及关键信息基础设施要形成自主研发能力，降低外部依赖、避免单一依赖。

· 研发平台——建立能够快速响应需求的敏捷研发运维体系，积极引入研发运维一体化工具，建设企业级一站式研发协同平台。

· 标准模块——主要业务系统实现平台化、模块化、服务化，加强企业架构设计，实现共性业务功能的标准化、模块化。

· 多活中心——优化数据中心布局，构建多中心、多活架构，提高基础设施资源弹性和持续供给能力。

我理解其核心要义还在是“自主可控”四字上。自主可控绝对不是指啥事都自己干了，完全不依赖于供应商了，这不仅没必要，而且是一种巨大的浪费，在“术业有专攻”和“越来越精细化”的大背景下，一定是擅长的人做擅长的事是对所有人都好。自主可控是解决被供应商拿捏的手段，但除了主观上想这样，还有什么方法论或是配套设施能“我的地盘我做主”又能“一个好汉三个帮”？答案就是“（甲方）搭台（多个乙方）唱戏”。先搭好一个台子，不仅仅是意识之台、管理之台、组织之台、流程之台，也是技术之台，而且往往是通过一个技术平台把意识、管理、组织、流程表现出来的。

这个技术平台叫什么？有人叫他技术中台、业务中台，有人叫他 PaaS，我们行云称之为企业数字化创新平台。叫什么其实无所谓，关键是有没有践行“搭台唱戏”的原则，是否能让甲方在数字化中“当家作主”，又能组织多个乙方“群策群力”，最终能聚力于数字化转型这个核心目标上。

后记

有朋友可能看完会说，这不就是“中台战略”嘛，人家 XXX 都已经不提中台了，中台是伪命题。首先我想说的，那个 XXX 其实还是提中台的，是中台的拥护者。其实，中台也好，PaaS 也好，搞好这些台子，特别是达到前述效果不太容易，涉及到的复杂因素蛮多的，数字化转型虽然急迫，但也不能“一口吃成个胖子”。无论选择什么样的建设思路或是技术路线，终究还是得研究透，这个过程中也是需要有供应商一起出谋划策的，而不是“闭门造车”。像行云这样的“见得多点、聊得多点、做得多点”，又长期聚焦于帮助甲方“搭台唱戏”的团队，我想能帮到您少走点弯路、做些即务实又长远的规划和建设。期待和您交个朋友，一起聊聊数字化转型那些事。

同角度的观点或是有趣的故事，还请您不吝赐教，期待能成为您数字化路途上的朋友。