企业数字化建设，自研还是采购？（自研篇）
软件是自研还是采购？
这是一个永远有争议的话题。
企业软件领域里有一个常年热门的话题：在做数字化的时候，到底是采购外部软件还是自研软件?
20年前，软件开发的成本和门槛相对较高，大部分企业的信息化工作都依靠商业软件，即使是那些超级大型企业，很多也是在商业软件的平台上进行开发定制工作。企业的IT部门常被戏称为“科技采购部”。
但是最近10年，技术和市场都发生了很大的变化，大家对软件采购和自研的争论也越来越多了。
“
2015年是人工智能、云计算、大数据大力发展的时期。从这一年开始，几个云计算公司的市值走势开始大幅超越传统软件和服务公司。
市场出现大量SaaS产品，各个细分模块都出现了很多创新的供应商，企业软件的采购和使用门槛进一步降低，用户体验大幅提升。
开源领域的各种组件和大型开发框架逐渐成熟，降低了自研的门槛。
全球供应链出现割裂和互不信任的现象，在软件领域也存在。
软件采购的门槛降低了，同时软件自研的门槛也降低了，所以才会出现各种各样的争议。有一些激进的观点认为，软件采购是传统IT的做法，现在要搞数字化，就必须自研。企业内部的不同技术派系、不同团队经常会为这个问题吵得不可开交。对于技术管理者来说，一个常见的难题是：当兄弟部门自研了一个解决方案，用还是不用？
今天先来讨论下那些适合自研的场景。
当核心业务进入无人区
先讲一个大家都非常熟悉的案例。2010年前后，一家大型商业连锁企业想进军互联网电商领域，自身的IT团队也已经超过千人的规模，虽然实力雄厚，但是面对电商这个新方向，其也存在研发体系和科技人员储备不足的问题。
这家商业连锁企业与当时行业内最知名的IT巨头合作，一起打造电子商务创新共同体。但是这家IT巨头本身并没有太多电商基因，电商解决方案相关团队不过几百人，在单个区域的团队规模就更小了。行业内的其他电商解决方案供应商规模也不大，很多是给传统企业做一个在线礼品商城，作为品牌的补充。
当年的IT巨头们更擅长于企业内部的应用，而中国电商的互联网用户的爆发，使得电商系统的规模要远大于企业内部应用的用户。在无人区里，普通的领航员没法给你提供有效的指引，最后可能只是起到一个背夫的作用，这时候你需要的是熟悉基本规律的探险家。
大家都希望从传统的线下连锁转型为电商领域的龙头，因为在电子商务领域具有马太效应，线上头部企业的扩张边际成本要远低于线下，而且极有可能形成垄断的护城河。在这样一个竞争前提下，市面上很难有成功的商业解决方案输出，当年的电商龙头亚马逊也不会轻易地把自身的电商体系解决方案交给第三方。
而同样是在2010年前后，中国两家电商企业，由于是从很小的规模成长起来的，在资源匮乏的时候没法依靠IT巨头，只能依靠自身团队搭建原生的电商体系，不断敏捷迭代，适应市场的变化，它们反而在快速增长和严酷竞争的市场环境中脱颖而出。
当一个业务是企业未来的核心业务，并且这个市场极具马太效应，大型玩家可能不超过3个，这时候没有选择，只能自研或者迅速并购市场上这个领域的其他软件供应商。2010年千人规模的科技团队，实力已经不弱于互联网电商。
如果企业的技术团队规模超过市场上这个领域的软件供应商，也应该选择自研。
延展思考
* 在业务的无人区里，除了技术和工程能力，其他什么能力更重要？
* 在自研的选择上，银行与证券公司会有不同的选择么？
● ● ● ● ● ● ●
当技术进入无人区
难道除了自研还有别的路么？
2000年进入互联网时代后，以搜索引擎和社交为代表的互联网体系替代了门户网站。互联网给数据技术带来的最大挑战就是数据量极大，但是单位数据的价值不高，在河里淘金需要的技术体系与金矿里炼金的技术完全不一样。如果技术成本太高，互联网企业就无法把搜索和社交网络搭建的成本通过精准广告体系变现。
谷歌最先解决这个技术难题，其在2003年后陆续发表了关于GFS、MapReduce 和 BigTable的论文，解决了数据存储、计算和处理的问题。谷歌也通过内部自研，攻克了互联网领域的这三座大山。但谷歌对外只是给了方向，并没有给出具体的解决方案，这个技术无人区使得其他的互联网公司陷入了困境。
雅虎首先参考这些论文，研发出了Hadoop技术体系并且开源，其他互联网公司Facebook、Amazon、百度、阿里、华为也逐渐拥抱和参与Hadoop的生态建设，使得其成为互联网技术重要的底座。光靠一家公司，可能很难支撑这么庞大的研发体系，也很难有那么多的验证场景，让产品得以持续迭代。
技术的无人区的探索成本难以估计，即使是财大气粗的互联网企业，也可能面临资源瓶颈和方向选择的风险。除了完全自研，开源和共建成为一种常见的模式。
延展思考
* 行业非头部的云计算公司，是应该自研一个闭源的分布式数据库产品，还是参与一个已经开源的分布式数据库产品？
* 互联网公司是否应参与竞争对手主导的开源项目？
● ● ● ● ● ● ●
从成本中心
转化为利润中心？
自研成本那么高，有么可能通过走出去来分摊一些成本呢？
这里分两种情况，一种是团队自己想走出去，另一种是企业希望团队走出去。很多团队在研发立项的时候，都会给企业决策者描述一个美好的未来：当前的投入，未来可以孵化出对外销售的产品和解决方案，毕竟很多工程师都有产品情节。还有一种情况是，当大规模的数字化建设进入业务平稳期后，企业很难再维持那么大规模的技术团队，管理层会希望将企业的技术团队从成本中心转化为对外的利润中心，靠着对外的业务来分摊企业成本。
历史上也有成功的案例。亚马逊的AWS起初也只是内部业务，后来转型成为专业的云计算平台，为其他企业提供云计算资源和服务。在一些硬件或者工业领域，成本中心转化为利润中心也有先例，很多汽车公司的配套子公司生产的零配件也会供应给竞争对手。
但是大部分行业，数字化投入后的产出，更多的是行业的解决方案，而不像标准的硬件或者工业品。一个具有马太效应的行业，稳定竞争状态下的玩家不多，一个企业是不太可能让竞争对手的技术团队来提供数字化技术的服务和支撑的，因为软件的实施和交付过程会暴露太多的商业信息。
想要把成本中心转化为利润中心，最重要的是搞清楚：客户是不是自己的竞争对手？是否能从过去的投入中提炼出标准的技术和产品来？输出的技术和产品未来是否能占据行业头部地位？
延展思考
* 一个航空公司需要在会员管理体系上投入多少开发资源？是否有可能对外输出？
* 大型银行设立的科技公司，哪些技术和产品有可能对外输出？
● ● ● ● ● ● ●
交易成本、信任成本和商务成本
成本能让人忽略掉大多数痛点，使人们不得不放弃专业的市场化服务，而转向DIY自我服务的模式。因为交通不便造成的交易成本，偏远山区的居民，大部分生活都是自给自足；因为信任的成本问题，育儿嫂这个领域的供应和需求都受到了挤压，大多数家庭都选择靠自己或亲戚帮忙带小孩；因为商务成本的原因，一些医疗费用高的国家里，居民有些小病小痛很少去医院就诊，基本靠自己的免疫力，偶尔也会借助成本相对低廉的止痛片度过难关。
软件和解决方案这样的非标准品，交易成本相对其他工业品和标品要高很多。
有些时候，需要解决的只是一个临时的痛点，但是决策成本、采购软件的流程成本和甲乙双方商定合同的时间成本累积起来可能要大于这个痛点的损失。假设解决痛点的收益是2万，购买专业软件的成本是5000，决策成本和时间成本是2万；自研解决问题因为不专业，成本略高，可能会是15000——那么在这个场景下，还是需要自研来解决这个痛点，或者是忍一忍，这个痛点很可能马上就过去了。
软件的交付过程也会带来很多信任问题。
对于0~1岁的婴儿，新手父母焦虑而缺乏经验，却有极强的保护欲，他们对第三方的育儿服务，无论专业与否都很难接受。即使是家庭内部，也很容易在这个时间段产生矛盾。但是过了几年后，有了一定经验的家长会比较安心地把3~5岁的儿童送到幼儿园，哪怕照顾一个4岁儿童的风险和需要消耗的精力可能超过一个半岁婴儿。
企业软件解决的问题可能涉及到企业的敏感业务和数据，例如客户的商机管理和薪酬管理。在这方面，很多企业的表现很像新手父母，他们会抗拒SaaS的模式，抗拒采购专业的软件。在这种情况下，自研是很多企业临时的选择，可以降低企业的焦虑感。但是自研也要注意方法，敏感数据即使是内部管理也很容易引起冲突，这种冲突不要上纲上线。
因为企业的需求决策链条长，很多需求并非固定不变的，即使是写在合同里，也可能会存在随时变更的问题，企业内部和甲乙双方经常会出现反复的争论。企业软件运行中出现的各种问题、故障诊断和归因分析也会非常复杂，有可能是因为软件、网络、硬件或者是操作不当。如果双方不善于妥协和磨合，很容易造成信任危机。
软件行业内也有非常复杂的定价和收费模式。
不同的定价方式，例如按用户数收费、按CPU 核数收费、按流量收费、按功能模块收费、按接口的数量收费……这些不同的定价策略，不仅会影响当前软件采购总价，也会影响未来场景发生变化时的成本。一些软件企业为了简化管理，把定价权完全交给代理商和销售，客户也会面临极大的不确定性。
企业在初次购买软件的时候，可能无法完全预测未来的使用场景范围，对于大型企业来说，会有非常大的成本风险。举个例子，当一个企业在试用推广一个软件的时候，可能会购买一个试点部门比如说100人的许可，如果使用和运营顺利、效果好，再在全员推广。
在这种情况下，系统架构规划师需要全盘考虑技术和商业的因素。如果一个企业不拥有这种规划能力，类似开源定价策略的软件，或者基于开源的自研体系，将成为企业敏捷创新的重要工具。
延展思考
* 对于小额软件采购，怎样降低决策成本、交易成本和时间成本？
* 开源软件、社区版软件和商业版软件怎样定价会有利于企业做决策？
● ● ● ● ● ● ●
软件供应链安全的困局
最近几年出现了很多影响全球供应链的事件，软件和开源领域也受到很大影响。例如一些软件巨头对某些国家断供，甚至是一些开源项目也对某些国家的用户进行限制和封锁。这些干扰使得很多企业越来越重视软件的供应链安全，思考极限生存条件下的软件体系建设问题。
如果把软件采购比喻成购买自来水，那么为了供应链安全而自研就类似于企业维护自己的水源。如果供应链体系不安全，在特殊时期，自己的水源地就是一种很重要的战略保障。战略保障体系，不作为日常的水源供应，而只是作为紧急时刻才启用的保障。对于这种场景，一般的企业不需要把自家后院的水井建设得像一个自来水厂那样配套齐全，因为那样要耗费过多的资源。对于像水井这样的Plan B软件体系，企业需要不断评估自身的核心业务和最精简的实现方式。假设出现软件断供，一个企业维持现金流需要哪些基础的业务？日常运行的复杂系统里，哪些是最必要的流程、最必要的数据？是否能在简单的Excel上实现75%的核心业务？
私有的水源也有一定的维护成本，后院的水井与其他地下水系也是相通的。对于软件来说，即使是自研，也需要评估每年的维护成本，评估哪些组件已经有被淘汰和出现漏洞的风险。一个软件体系如果常年不更新，就会面临变质的问题，比如可能没法适配最新的操作系统和浏览器。
总结
在下面这几种情况下需要考虑自研
业务进入无人区
技术进入无人区
企业在细分赛道的技术资源超过这个领域里的软件供应商
有可能将自研的投入转化为标准技术和产品，并占据行业前几名，实现从成本中心到利润中心的转化
过高的交易成本、信任成本、摩擦成本和商务成本
应对软件供应链安全的Plan B计划
以后有时间还会谈一谈企业对外采购软件的场景，在大多数情况下在，市场竞争会带来更专业的分工，软件行业也不例外。
T H E E N D
长
按
关
注
信息化与数字化
EVERY HERO HAS A CODE