云原生集成开发环境——TitanIDE
通过网页在任何地方更安全、更高效地编码2023-03-09
657
原文作者:行云创新CEO 马洪喜
“老马闲评”系列文章正在“深圳行云创新”公众号连载,感兴趣的朋友请关注我们的公众号,不迷路……
导语
开年过后业务特别的繁忙,出差也比较多,所以有段时间没更新了,对不住大家!
上一集(您可以查看“行云创新”主页阅读原文)咱们聊了数字化转型的“想转、急转、不敢转”的企业现状,主要还是有很多担心,比如:到底是业务部门还是技术部门牵头,这就是首当其冲的问题。今天,我们再聊聊其他方面的担忧,就拿“数字化转型是否会被供应商拿捏住”这个事开聊吧。
正文
老马我大学毕业就做乙方了,从来没体验过甲方的快乐和苦恼。但是,这么多年我结交了各行各业、国内国外甲方的好朋友,在闲聊中也体验到个中滋味。所以我经常对我的伙伴们说,签合同前甲方是牛气,签完合同就不同了。如果乙方搞砸项目,最多就是收不了款拍拍屁股做了下一个项目,但甲方面临的是烂摊子,当初支持乙方的甲方领导可能因为这个项目影响到他的职业生涯。所以,作为乙方要有“如履薄冰”的心态,做“对得起朋友,不辜负信任的事儿”。
供应商不认真做事还不能算是被其拿捏,最多是当初看走眼,自食其果。那是否有供应商通过低价或是其他的策略进入一期项目,想进去后通过二期盈利呢?虽然这对大家都不太好,但目前来看这种现象是有的。不仅私有云有,公有云也蛮多的,给予新客户极大的折扣,来年就恢复原价。但我个人认为,虽然不太爽,但考虑到更换供应商的成本和对方确实此前付出了很多,只要不是太过分的,大多甲方还是会通过谈判与乙方继续合作,这种也不能算是拿捏。
真正的“拿捏”往往是不受甲乙双方之可控,但对双方特别是甲方影响甚大,我列举以下几个示例。
前一天还一起加班,第二天被通知离场,项目中断。我听说这么一个故事,某甲方公司项目组和某外企供应商的咨询团队长期合作,一起加班熬夜上线系统,一起宵夜烧烤啤酒,都混成兄弟了。突然间外企的咨询团队收到内部邮件,由于该甲方公司被A国列入所谓的“实体名单”,所以必须马上停止提供技术服务。可想而知双方项目人员都是懵逼的,其对项目的影响也是巨大的。这种情况可以称之为“黑天鹅式拿捏”。
没有一个是错的,但加在一起有点不对。多供应商参与信息化、数字化建设很普遍,在精细化分工大趋势下,未来将是越来越如此。在传统合作模式下,特别是分不同包离岸开发的场景,不同的乙方都有一套自己的“玩法”。就拿中间件来说,有的用Kafka, 有的用RocketMQ,有的用RabbitMQ,选择什么中间件、技术框架大多是看乙方架构师、程序员的个人擅长或是喜好。各自都没错,但当有这样的若干个项目交付给甲方之后,甲方的运维人员是一头包:他们面临N多种技术组件的N多个版本,监控手段、安全手段、排错和备份手段都不一样。这样的尴尬情况可以称之为“群体性拿捏”。
痛点不大但很痛,求人求己皆不能。我有一个客户,他们在制造业也算头部了,很多业务系统早就建成了,但当初建设的时候都是一个个垂直的烟囱,没有考虑到有一天需要一个横向的流程,跨越多个系统往复交互数据。这个需求还没有大到专门申请一笔预算立项、招标、采购、项目管理、验收。而且这个痛点的“痛法”恐怕也是独特的,没有供应商驾轻就熟,最多就是在众多烟囱系统间再横上个杆子。问题是类似的痛点不止一处,未来还有新的痛法,“治标不治本”的方法只能让事情更复杂。这个局面不是任何一个供应商造成的,我们称之为“自我拿捏”。
前面第二集(您可以查看“行云创新”主页阅读原文)中提到,数字化转型是“求活路”,本质是靠自己,如果轻易的靠某个供应商的某个业务系统就数字化成功了,那就不叫转型了,所以“自主可控、数字化命运掌握在自己手中”是数字化转型的核心要素。
前面提到的三个“供应商拿捏”的情况,我们再分析一下:
· 黑天鹅式拿捏——根因是过度依赖单一供应商,没了他,项目玩不转了。
· 群体性拿捏——根因是没有建立一套甲方自己的标准,任由不同供应商各搞各的。
· 自我拿捏——无论在流程还是技术上,都缺少跨供应商、跨业务系统的协同能力。
无论哪种情况的避免,都需要甲方有自主可控的数字化建设思维。这种思维体现在意识、管理、组织、流程、技术等多个维度。
金融领域一直是数字化建设的排头兵,也是国家层面数字化指导政策的风向标。早在去年年初,就有《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》一文,该文高屋建瓴的给出了一些具体的指导意见,老马深表赞同,也建议跨行业的朋友认真的研究参考一下,这里引用几点具体的意见:
· 自主研发——对关键平台、关键组件以及关键信息基础设施要形成自主研发能力,降低外部依赖、避免单一依赖。
· 研发平台——建立能够快速响应需求的敏捷研发运维体系,积极引入研发运维一体化工具,建设企业级一站式研发协同平台。
· 标准模块——主要业务系统实现平台化、模块化、服务化,加强企业架构设计,实现共性业务功能的标准化、模块化。
· 多活中心——优化数据中心布局,构建多中心、多活架构,提高基础设施资源弹性和持续供给能力。
我理解其核心要义还在是“自主可控”四字上。自主可控绝对不是指啥事都自己干了,完全不依赖于供应商了,这不仅没必要,而且是一种巨大的浪费,在“术业有专攻”和“越来越精细化”的大背景下,一定是擅长的人做擅长的事是对所有人都好。自主可控是解决被供应商拿捏的手段,但除了主观上想这样,还有什么方法论或是配套设施能“我的地盘我做主”又能“一个好汉三个帮”?答案就是“(甲方)搭台(多个乙方)唱戏”。先搭好一个台子,不仅仅是意识之台、管理之台、组织之台、流程之台,也是技术之台,而且往往是通过一个技术平台把意识、管理、组织、流程表现出来的。
这个技术平台叫什么?有人叫他技术中台、业务中台,有人叫他PaaS,我们行云称之为企业数字化创新平台。叫什么其实无所谓,关键是有没有践行“搭台唱戏”的原则,是否能让甲方在数字化中“当家作主”,又能组织多个乙方“群策群力”,最终能聚力于数字化转型这个核心目标上。
后记
有朋友可能看完会说,这不就是“中台战略”嘛,人家XXX都已经不提中台了,中台是伪命题。首先我想说的,那个XXX其实还是提中台的,是中台的拥护者。其实,中台也好,PaaS也好,搞好这些台子,特别是达到前述效果不太容易,涉及到的复杂因素蛮多的,数字化转型虽然急迫,但也不能“一口吃成个胖子”。无论选择什么样的建设思路或是技术路线,终究还是得研究透,这个过程中也是需要有供应商一起出谋划策的,而不是“闭门造车”。像行云这样的“见得多点、聊得多点、做得多点”,又长期聚焦于帮助甲方“搭台唱戏”的团队,我想能帮到您少走点弯路、做些即务实又长远的规划和建设。期待和您交个朋友,一起聊聊数字化转型那些事。
同角度的观点或是有趣的故事,还请您不吝赐教,期待能成为您数字化路途上的朋友。