企业软件为啥不能组件标准化、模块化？

微博上有朋友问：十来年前很多ERP类企业软件就号称模块化、积木化、业务组件化，按需拼装，即插即用。今天来看，还是忽悠成分居多。企业软件的组件不能标准化、模块化的原因是什么？


因为此话题说来话长，所以特写一篇博文以回复。


一、企业软件的组件为啥不能标准化？


企业软件是映射企业现实的。只有给企业现实建立3D扫描模型，才能很好的把这个企业3D扫描模型转换为企业软件。


有什么工具、方法来把企业现实做成企业3D扫描模型呢？这就是企业业务建模。


我个人的企业业务建模方法是：


1、业务流程层面，通过 组织流程法来建模。先定义企业的组织层级/部门、岗位。再逐一定义每个岗位的职责。再逐一把每个职责展开为一级流程和二级细化流程。再把每个流程节点的输入输出详细格式要求定义出来。这样就把业务流程层面建模起来了。这就类似给企业的业务拍个照片。但依照这样的业务流程模型做出来的软件，也就就是个企业E化，对改进企业的问题帮助并不大。不过，对于中国企业还是合适的。因为大部分中国企业连自己的组织/岗位职责都说不清楚，管理水平还处于一屁股坐在地上的水平。


2、但是，企业养了这么多细分专业细分岗位的人，成立了这么多部门，其实都是为了支撑企业的战略目标的。这些都是企业的资源，而企业的资源又不是无限的，所以就需要做好 企业资源规划。首先要确定企业的战略，分解战略到行动方案/行动组织/行动计划/行动考核。这样就可以调动企业所有资源，打穿各个部门各个岗位，组织整合资源，为企业战略支撑实现而服务。企业的主干不外乎是生产、销售、服务这三大块。所以需要围绕这三大块开展打穿整个链条的业务模型。在这样业务模型基础上建立的企业软件，才是真正的企业级管理软件，因为这个模型是站在整个企业的视角上看问题的，不是一个部门的业务E化这么简单。


3、但是这样的企业软件还不能称作为ERP。因为ERP是企业资源计划。计划是要PDCA的，要管控关键节点、关键产物。所以必须在这样的链条 内置PDCA，才是真正意义上的企业资源计划。


4、但这样做后，还没有洞穿本质。毕竟企业是通过做事而去赚钱的。而我们上述几个步骤都在细研如何做事。但企业经营不是事情做了目的就达到了，不是目的达到了就赚钱了。很多企业员工把事做了，把事当成了目的，以为事做了目的也就顺理达成了。这样的思维是错的。所以需要在流程的每个关键流程节点中要内 嵌财务收支预测、管控、核算这条线。


你看，一条支撑战略行动的打穿业务链条，附上业务管控层的PDCA，再附上财务管控层的PDCA，这才是一个丰满的企业业务建模。


这样做出来的企业业务模型，才是最体系、结构、完备的业务模型。只有通过这样业务模型而映射出来的企业软件，才是真正有实力的企业软件。


但话说回来了，随便找一家ERP软件提供商，我看看谁是这么干的？谁能理直气壮的立刻拿出这些东西。我相信很少ERP软件提供商能拿出来。


ERP软件商也是企业，只要是企业，就能应用企业资源计划，就得需要战略管控、业务管控、财务管控。所以我说企业资源规划ERP不是MRP的一个扩展。所以我也老说哪个ERP软件商自己不用ERP，就是耍流氓。如果一个ERP软件商自己的战略管控、业务管控、财务管控都没有章法没有方法，那它做出来的ERP软件也一定是没有方法的。也就是说，大部分ERP都是假ERP，其实只是按照我说的第一层：组织流程法来机械映射的。所以只要企业组织、业务流程一变化，这套ERP就不适合用了。核心原因就在于此。


二、企业软件的组件为啥不能模块化？


这个问题的核心是企业业务流程是链条状的，而模块化的本质是独立封闭解耦的。链条和独立，这就形成了天然的阻抗。


分分合合，关键就在于先解耦，然后怎么串起来。这样就既独立又联合，又有珍珠又有项链。但要想把珍珠串成项链，需要每颗珍珠有窟窿眼。在软件领域中这被称为接口。


企业有很多的部门，这都是人为划分的。部门可以不断组合拆分。企业也有许多的岗位，每个岗位也有职责，但这些岗位以及岗位的职责都是人为划分的。都可以根据企业变化不断拆分。而企业对外提供的服务相对比较固定，一般增加的服务也是现有服务的一个上下游延展，不太容易能出现一个全新的服务。因为能提供什么服务，这和企业的能力有关。除非企业新增加新的业务线，外招或培养新的能力、新的岗位，以提供新的服务。


这样来看，按组织流程法、按战略行动法梳理得来的业务模型，想映射成软件，还不容易模块化。只有 从企业对外提供的服务，从外向内来梳理，得出的业务接口才是相对比较稳定的，再经过技术架构接口设计，那么接口也就容易形成可扩展、向下兼容性的接口。


这种梳理方法，从咱们业务模型梳理方法来看，属于以客户为起端的打穿业务链条方法。这比企业战略行动从上到下梳理的方法还要稳固。因为中国内外环境多变，中国企业主又尤其爱超车，所以企业的战略也往往连年变化、重点各有不同。而从客户角度发起业务链条打穿，客户是一切的根，是企业的衣食父母，客户的满意和贴近才是正道。所以，我比较推崇这种方法，先做好客户关系管理。客户关系管理是一个体系、一个战略，以此细化有客户细分、 客户体验流程再造等。但往往很多企业其实并不了解他自己的客户。说来别笑，真是这样，看似天天销售、服务跑客户，其实是在跑单子，对客户的关键人需求、产品使用情况和不满意地方并不了解。所以说，要做客户细分、客户体验流程再造，首先去了解你自己的客户。


为什么讲模块化，就又讲起了业务模型梳理方法又讲起了客户关系管理？其实质就是试图找到一个相对稳定的描述企业业务模型的方法。只有在相对稳定的企业业务模型之上梳理的接口才是相对稳定的。


有了稳定的模型和清晰的接口，模块化就容易形成既独立封闭，又相互关联。但这还并不足以解决企业业务流程的流状性和模块独立性的天然阻抗。


我们知道，企业软件往往是通过一些状态值来控制模块和模块之间的关联，数据和数据之间的关联。在咱们社会有红绿灯，三种状态，但在企业状态中往往有更多的状态。这就不能用咱们开关这种简单的方法来控制。虽然在IT界提供了企业服务总线进行服务之间的连接、数据之间的传递、消息之间的传递，但毕竟它只是提供了一个技术实现方法，到了具体的业务模块之间的流转，还需要我们画出状态图。


但每个流程节点都可能有N种状态，这么多节点，这么多状态，之间的互相影响关系是什么，状态复杂了，就会遗漏影响关系。这就类似牵一发动全身。所以现在又有一些算法专门用于校验 状态机相互依赖性。这在一些RPG和即时战略游戏中常用。所以这也是我研究这些游戏机制的原因。


只有这样设计出的软件，才能真正模块化。