我在上一篇文章中提到，企业软件行业由供应商、客户和第三方组成，为企业提供的数字化能力包括具备标准能力的产品化软件、提供定制化开发服务和人力资源外包的软件服务商、客户的IT自研团队等。
这些力量如何组织在一起形成数字化能力？
我总结了自己的实践经验和观察，做了这个表格，今天给大家详细介绍一下：
【模式一：离散应用系统】
离散应用系统是根据用户需求量身定制的软件，从大型的完整定制系统到小型的烟囱式独立模块。
为了满足个性化需求而构建的系统，会随着业务规模的扩大、需求的不断调整，逐渐暴露出各种问题，不断增加的补丁、新的功能也会不断冲击系统的安全性和稳定性，最终系统烂到无法持续，不得不推倒重建。
尤其是进入大数据时代后，离散系统产生的数据缺乏标准化设计，如果要突破数据孤岛就必须做数据治理，系统改造周期长、成本高。
后人可以从鸟瞰的角度批判离散模式系统所存在的系统种种问题；但是这种模型也有它的优点，适合特定的场景。
对于初创企业或者成熟企业中的创新业务来说，往往需要利用有限的时间窗口，通过反复试验进行快速探索。
此阶段需求在不断迭代完善，甚至反复调整。如果需求不固化，应用系统缺少稳定的运行环境，可靠性、稳定性等指标就不会好看；而对新需求的响应速度、变更上线速度是此阶段评判系统好坏的最重要因素。
到了这个阶段，应用软件系统负责人说这个不行，那个不符合标准，还要一年多时间才能改，你觉得业务部门、公司领导会打你吗？
【模式二：中心化应用体系】
顾名思义，集中式就是多个用户共用同一个系统、平台，或者不同的用户使用相同的功能。因此，集中式也存在一种变体，即使用标准化的非定制化产品软件，同样为不同的用户提供完全相同的功能。
中心化的应用系统有规模经济，规模越大，成本越低，边际成本下降，这是供给方最希望看到的。
集中式应用系统的另一个好处是软件可以统一升级迭代，即使用户不提出任何需求，只要系统更新升级，就能获得最先进的能力。
但这种模式的缺点也是明显的。
无论是集中部署的系统，还是产品化的软件，更新迭代大多是由供给方发起的，新技术的引入、架构设计的优化、功能的增加和调整都要统筹考虑，尤其是功能的调整不会满足所有客户的需求，而是对各方面反馈进行梳理、评估，最终形成研发需求。
如果是小众客户的需求，或者评估后认为不足以纳入新版本，那就意味着需求被拒绝，这对于产品供应商来说，不算什么大问题。
即使采纳这个要求，按照产品开发流程规划，也需要完成需求分析、概要设计、详细设计、编码、测试等一系列标准化动作才可以交付。而且交付后的软件安装适配也需要时间，这一系列工作难道要花上几个月的时间吗？
需要注意的是，这还是理想状态，实际操作中可能会受到各种因素的干扰，或者要增加一些环节，导致周期变长。
是不是因为某个客户比较着急，我们就先把重要的功能发布给客户使用呢？抱歉，产品化的软件是不允许这样的！
至于其他问题，例如一个软件包中含有很多客户不需要的功能，但客户在购买时仍需付费，而且还要提供冗余的硬件设施来匹配，增加了硬件成本和运营成本等等，这些只要多花一点钱就能解决的，都是比较小的问题。
因此集中式模式适合部署在比较成熟、需求相对固定的大型企业，尤其是那些试图借助软件系统提升自身管控能力的企业，采用产品化的软件，通过集中式部署，可以消除各种差异性和特殊现象。
如何让客户的需求趋同，避免提出个性化的开发任务，是令供应商头疼的难题，在中心化的体制下，个性化的需求可能会被客户通过行政手段压制。
当企业处于稳定的运营状态时，希望通过实施精细化管理来提高效率软件上线部署实施 外包公司承担什么责任，因此愿意减少各级灵活操作的空间。此时采用集中管理，通过产品化来统一思想、统一行动。企业在实现权力集中的同时，也推动内部降本增效。
【模式三、组合应用体系】
组合式是指将不同的软件、系统、模块组合在一起，为企业客户提供所需的能力。
组合方式也可以分为两类，一类是产品化软件与定制开发的组合；另一类是各类产品化软件、模块组合形成能力。
模块化系统通常构建如下：
1、按规划建设系统，并在系统建成后提供既定的数字化能力。
2、若需求发生变化，尽量先通过产品配置来完成；
3、如果无法配置，看能否通过与其他产品结合来满足；
4、如果还是搞不清楚，可以使用定制服务开发来提供备份。
相对于集中式模式，模块化模式更能满足客户的个性化需求；而相对于离散式模式，模块化模式又有产品化的内容。因此，模块化模式既兼顾了产品的标准化，又兼顾了定制的个性化，既兼顾了服务的灵活性，又兼顾了产品的稳定性。大家各司其职，发挥各自的优势。最终，定制化服务才是底线，永远都是要做到。
但在实践过程中，我也看到了结合存在的一些问题。
首先，如果是为了达到某个既定的目标，产品+服务的模式的成本可能不是最优的。
每个产品化软件提供的功能都是有限的，如果大量的功能需要服务商来做，那么最好全部定制，可以省去一些接口适配和集成的工作。
因此，虽然两种服务都是为了满足客户的个性化需求，但组合模式的成本会比单纯的定制服务更高、资源要求更高、开发周期也会更长。
其次，组合模式需要多个厂商协作，无论是产品+服务，还是直接的产品组合。
无论故障发生在系统建设过程中，还是运行过程中，都可能涉及不同厂家之间的责任界定、能力确认、利益分配等问题。
人们只抓那些容易做、能赚钱的功能，不抓那些难做、费力气的功能，技术问题被拖来拖去，简单的问题被复杂化。
而且如果产品可配置项较多，或者软件能力由多个产品组成，配置工作可能会变得过于复杂，甚至超出配置人员的能力。
曾经在一个项目中，我看到负责产品配置的人是一个很资深的研发人员，因为除了他之外没有别人能做这个工作。
这还不是最可怕的。
在各个组合系统中，各个厂商都有各自的产品演进策略和产品方下达的升级计划，当出现矛盾冲突时，协调往往非常困难。
网上运行的系统某个主要产品突然需要升级怎么办？
首先，我们需要分析升级可能涉及的内容，然后评估对现有组件的影响，然后制定调整计划并实施。如果出现问题，这几乎就像从头开始重建系统一样。
完工仅仅两个月后，就收到通知，又有一个重大产品需要升级。
成年人往往一瞬间就会崩溃。
[企业软件必须适应企业的发展。一个人的美味佳肴可能是另一个人的毒药。]
放眼未来，各行各业的数字化程度必然会越来越高，企业无论进攻还是防守、求变还是求治理，都需要企业软件的支持与配合。
企业在不同发展阶段对数字化能力的要求不同，部署模式也需相应调整。
我认为，企业软件的能力构成模型没有唯一的标准答案，数字化能力必须适合企业的发展现状，每一种存在模型都有其合理性。
总体来说，组合是企业平衡稳定性与创新性的最佳选择：成熟的产品化软件稳定输出，提供有界的能力；创新则通过产品组合或者定制开发来实现。
但如果客户的需求能够被产品化的软件充分支持，或者用户比较被动，只能使用有限的功能，那么集中式的方式是最好的。
但如果顾客需求不能固化，且经常变化，特别是规模较小的情况下，离散模型还是比较好的。
核心是：企业软件不能被动地限制企业发展，而必须主动地帮助和支持企业成长。
企业在运营阶段，努力降低成本、确保稳定可靠；遇到创新突破的机会，要采取积极的心态。
当需要对数字化能力进行较大的改变时软件上线部署实施 外包公司承担什么责任，可以先采用离散的方式，用独立的系统去试错，等需求稳定之后，再研究最佳的实现方式。
来来回回，在变化中寻找机遇。
所以我认为在这个过程中，企业应该逐步培养自己的IT能力，承担产品组合配置、定制化开发、系统集成等任务。
这是企业客户构建自身数字化能力的最终选择。
