上一集您可以查看“行云创新”主页阅读原文咱们聊了数字化转型的“想转、急转、不敢转”的企业现状主要还是有很多担心比如到底是业务部门还是技术部门牵头这就是首当其冲的问题。

今天我们再聊聊其他方面的担忧就拿“数字化转型是否会被供应商拿捏住”这个事开聊吧。

老马我大学毕业就做乙方了从来没体验过甲方的快乐和苦恼。

但是这么多年我结交了各行各业、国内国外甲方的好朋友在闲聊中也体验到个中滋味。

所以我经常对我的伙伴们说签合同前甲方是牛气签完合同就不同了。

如果乙方搞砸项目最多就是收不了款拍拍屁股做了下一个项目但甲方面临的是烂摊子当初支持乙方的甲方领导可能因为这个项目影响到他的职业生涯。

所以作为乙方要有“如履薄冰”的心态做“对得起朋友不辜负信任的事儿”。

供应商不认真做事还不能算是被其拿捏最多是当初看走眼自食其果。

那是否有供应商通过低价或是其他的策略进入一期项目想进去后通过二期盈利呢虽然这对大家都不太好但目前来看这种现象是有的。

不仅私有云有公有云也蛮多的给予新客户极大的折扣来年就恢复原价。

但我个人认为虽然不太爽但考虑到更换供应商的成本和对方确实此前付出了很多只要不是太过分的大多甲方还是会通过谈判与乙方继续合作这种也不能算是拿捏。

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

前一天还一起加班第二天被通知离场项目中断。

我听说这么一个故事某甲方公司项目组和某外企供应商的咨询团队长期合作一起加班熬夜上线系统一起宵夜烧烤啤酒都混成兄弟了。

突然间外企的咨询团队收到内部邮件由于该甲方公司被A国列入所谓的“实体名单”所以必须马上停止提供技术服务。

可想而知双方项目人员都是懵逼的其对项目的影响也是巨大的。

这种情况可以称之为“黑天鹅式拿捏”。

没有一个是错的但加在一起有点不对。

多供应商参与信息化、数字化建设很普遍在精细化分工大趋势下未来将是越来越如此。

在传统合作模式下特别是分不同包离岸开发的场景不同的乙方都有一套自己的“玩法”。

就拿中间件来说有的用Kafka,

有的用RocketMQ有的用RabbitMQ选择什么中间件、技术框架大多是看乙方架构师、程序员的个人擅长或是喜好。

各自都没错但当有这样的若干个项目交付给甲方之后甲方的运维人员是一头包他们面临N多种技术组件的N多个版本监控手段、安全手段、排错和备份手段都不一样。

这样的尴尬情况可以称之为“群体性拿捏”。

痛点不大但很痛求人求己皆不能。

我有一个客户他们在制造业也算头部了很多业务系统早就建成了但当初建设的时候都是一个个垂直的烟囱没有考虑到有一天需要一个横向的流程跨越多个系统往复交互数据。

这个需求还没有大到专门申请一笔预算立项、招标、采购、项目管理、验收。

而且这个痛点的“痛法”恐怕也是独特的没有供应商驾轻就熟最多就是在众多烟囱系统间再横上个杆子。

问题是类似的痛点不止一处未来还有新的痛法“治标不治本”的方法只能让事情更复杂。

这个局面不是任何一个供应商造成的我们称之为“自我拿捏”。

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

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

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

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

无论哪种情况的避免都需要甲方有自主可控的数字化建设思维。

这种思维体现在意识、管理、组织、流程、技术等多个维度。

金融领域一直是数字化建设的排头兵也是国家层面数字化指导政策的风向标。

早在去年年初就有《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》一文该文高屋建瓴的给出了一些具体的指导意见老马深表赞同也建议跨行业的朋友认真的研究参考一下这里引用几点具体的意见

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

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

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

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

我理解其核心要义还在是“自主可控”四字上。

自主可控绝对不是指啥事都自己干了完全不依赖于供应商了这不仅没必要而且是一种巨大的浪费在“术业有专攻”和“越来越精细化”的大背景下一定是擅长的人做擅长的事是对所有人都好。

自主可控是解决被供应商拿捏的手段但除了主观上想这样还有什么方法论或是配套设施能“我的地盘我做主”又能“一个好汉三个帮”答案就是“甲方搭台多个乙方唱戏”。

先搭好一个台子不仅仅是意识之台、管理之台、组织之台、流程之台也是技术之台而且往往是通过一个技术平台把意识、管理、组织、流程表现出来的。

这个技术平台叫什么有人叫他技术中台、业务中台有人叫他PaaS我们行云称之为企业数字化创新平台。

叫什么其实无所谓关键是有没有践行“搭台唱戏”的原则是否能让甲方在数字化中“当家作主”又能组织多个乙方“群策群力”最终能聚力于数字化转型这个核心目标上。

有朋友可能看完会说这不就是“中台战略”嘛人家XXX都已经不提中台了中台是伪命题。

首先我想说的那个XXX其实还是提中台的是中台的拥护者。

其实中台也好PaaS也好搞好这些台子特别是达到前述效果不太容易涉及到的复杂因素蛮多的数字化转型虽然急迫但也不能“一口吃成个胖子”。

无论选择什么样的建设思路或是技术路线终究还是得研究透这个过程中也是需要有供应商一起出谋划策的而不是“闭门造车”。

像行云这样的“见得多点、聊得多点、做得多点”又长期聚焦于帮助甲方“搭台唱戏”的团队我想能帮到您少走点弯路、做些即务实又长远的规划和建设。

期待和您交个朋友一起聊聊数字化转型那些事。

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