软件包 or Not

今晚听了自己大部门关于软件包的辩论，辩题是“全面坚持软件包驱动是利大于弊还是弊大于利？” 不少观点还是值得思考。

结合了今晚各位前辈的发言，总结了一下个人的观点。

选择是否采用软件包，需要从以下的方面去考虑：

1. 负责实施的部门的资源情况，人员结构（包括能力结构和职责结构），预计的人力和资金投入

2. 软件包成熟度，包括从业务方案以及技术方案上考量

3. 交付进度计划

从我个人观点来看，1和2其实是最最重要的。

首先对于第一个考量点，出发点是在于，负责实施部门所具有的资源情况不同的话，会对是否采用软件包驱动的方式产生很大影响。为什么这么说？

因为相比起采用软件包，自己研发系统所需要的技术人员的水平以及数量会比实施软件包的高和多。这应该是比较明显的，因为假定我们能采用的软件包都是处于业界比较先进的水准的（这个假定其实跟第二个考量点密切相关了），若自研系统需要达到或者接近这个水准的话，就需要相当高水准的架构人员，设计人员以及开发人员。按我们的假定，软件包应该是经过不少的业界案例的实践，稳定性，扩展性应该是比较高，自研系统要做到这一点的话，人员的投入自然成本会提高，另外有的东西不单需要人力，还需要时间，例如系统的稳定性，纵使设计再优秀，也很难避免会有这样那样的bug，这些bug都需要时间去发现和稳定下来。

由此可见，自研系统的人力成本以及时间成本都会比较高。虽然软件包实施往往也需要聘请价格不菲的顾问，但我觉得上从金钱和时间成本上去衡量，还是自研系统的成本更高。

人员结构方面，由于自研系统需要更多高水准的技术人员以及方案人员，若实施部门不是公司中最核心（最赚钱）的部门的话，往往难以投入大量精英，可能导致自研系统的种种瓶颈。

所以第一个考量点我觉得其实是相当有决定性的。今晚其实有前辈提到淘宝的例子，他们的系统也是采用自研，能够抵挡住光棍节恐怖流量的冲击，软件包也不一定能做到。对这个例子，我觉得对于淘宝，这些交易系统就是命根子，是最核心的东西，当然会投入最好的资源到里边，所以采用自研是完全能够Hold住的。而对于某公司的某项目，只是公司内部使用的一个IT系统，虽然也被提及是影响公司未来发展存亡的变革项目的核心，但个人感觉怎么说也不是最核心的产品，所以自然投入是会打折扣。

对于第二个考量点，也是十分具有决定性的。软件包之所以吸引，很大程度上光环是集中两方面，第一，所包含的流程思想。第二，所采用的技术架构。

流程思想总是很具有吸引力。因为对于IT系统，谁都能做个出来，不一定非得oracle, microsoft，要有什么功能在技术上都有方法可以实现。但是流程思想这些东西，可不是一般的屌丝能想得出来，没有一定的眼界和经验，真的是玩不转。所以软件包其中一个吸引人的地方就在于其所包含的经过锤炼经过实践检验的流程思想。我们总寄望于通过实施软件包，能吸纳其流程思想上的精华，优化和梳理已有的流程。让屌丝的内在得到升华，真正从暴发户迈入高富帅的行列。

技术架构相对于流程思想，会相对实在一点，但也是没有一定的眼界和经验，也无法拿出一个真正优秀的经得起考验的架构。

所以考量一个软件包是否值得采用，流程思想和技术架构是否足够成熟，是否在业界有足够的竞争力，这是十分十分重要的指标。

至于第三点对交付进度计划的考量，原因其实在第一点也覆盖到了，自研系统需要更多的人力物力和时间，相对而言是采用软件包驱动会更适合进度要求高的项目。

转载于:https://www.cnblogs.com/ausserwelt/p/3141463.html