企业管理系统IT基础组件化的一些思考（1）----基于一次对新员工的交流

近期有实施的新同事加入我们团队，由于有较长的工作经验，在对公司主要产品进行了初步了解后，找他进行了一次交流，并产生了企业管理系统it基础组件化的一些思考。

当他把这几天了解到的内容跟我讲解后，我认为整体思路没有问题，可以从整个架构层面进行一次初步讲解。

第一个讲解点：由于他给我的第一个问题是：为什么在管理产品账号的时候需要引用员工信息？

解析：企业管理软件的服务对象是谁，受众对象又是谁？

企业管理软件，服务主体是企业，使用对象时员工，而员工的基本信息是hr系统中已存在的内容，基础信息是全集团共享的，所以，在企业管理软件中，组织结构组件就是一个标准组件，基础数据一般来自于hr系统。由企业内部主数据系统进行分发。

所以，在企业管理软件中，账户信息必然会与企业组织结构中员工信息进行关联。

如果存在员工在集团内部不同的部门交叉认证，将需在系统中引入登录身份（登录岗位/部门）进行业务区域。这就是企业管理软件与公众化软件平台对账户处理的差异。

第二个讲解点：产品中根据业务建立很多数据录入入口，统计入口等

解析：我们的开发并不知道这些内容

产品中有，但为什么开发团队不不知道这些内容呢？我们是一家产品公司，团队分为产品组/实施交付组。

产品组关注基础组件/标准业务工序/实施运维工具等完善。

实施交付组关注目标客户的业务细节，在产品平台上搭建与目标客户需求一致的业务应用平台。

所以，开发是可以不需要了解目标客户的具体功能的，就像开发团队内部，也只有少量人员能对整个产品进行解析，内部使用的也是标准化的基础组件。交互基本为整合后使用标准的接口，最多是在内部组件中调用特定组提供的sdk工具。

产品组与交付组共同的知识是什么？

业务功能列表/功能编号/功能名称/来源编号/工作流/报表/组织结构/权限等内容

业务功能列表：提供了实施交付团队在客户现场完成业务调研后业务功能抽象的功能存在能力。如：合同起草/案件上报/规章制度管理等

功能编号：业务功能列表的主键，在整个业务平台中统一使用，并用于区分特定业务的代号。

功能名称：

来源编号:一般为全局唯一的有规则的业务数据组件，由编码组件生成。对应的还有业务物理组件编号，全局唯一的流水号，当前采用基于时戳的雪花算法提供

工作流：我们当前有.net与Java两个产品，.net版本工作流为完全自主研发的工作流平台，已经经过7年/几十家规模企业长时间在线验证；java版本是在flowable6.5基础上，构建的一个中立的工作流运行平台。两个产品基本都能满足规模企业应用。

报表：管理软件最高的服务职能体现

组织结构：企业组织形式的数字化体现，并且在企业内部管理系统中原则上是统一的内容。

权限：基于组织结构构架的软件功能使用与业务数据权限的控制主体，涉及到企业内部数据资产安全的核心组件。企业管理软件的权限是一个交叉模式：如果组织结构中/组织部门维度/岗位维度/人员维度/角色维度，组合的模式实现最终用户权限。

所以我们常说：企业管理软件做的就是：单据-->流程-->报表。从18起，内部推动的变成了：单据-->流程--->报表--->主线