协同制造云，如何实现汽车供应链的数字化转型？

在工业4.0和智能制造发展的驱动下，以中国制造2025为背景，汽车整车企业为了实现精益化的制造及物流，提升生产和物流的质量和效率，建立高效、灵活、稳定、透明的供应链体系变得尤为重要。面对多样化的市场，整车企业的产品交付、成本控制、质量追溯将面临多维化、高效率、高标准的要求，而供应链的数字化转型成为了整车企业快速响应市场，提高产品质量的必经之路。本文以某整车企业为原型（以下简称A公司）结合其供应链数字化转型的经验来探讨国内众多整车企业建立其智能化、数字化供应链体系面临的问题和挑战。

 

为了降低物流成本、缩短产品交货期、提高供应商间配合的契合度以提高产品质量，A公司计划实施供应链管理系统，以实现整车计划实时下发到几百家供应商进行零部件生产计划拆解生产，同时监控各供应商生产过程、质量数据以及质量改进，初期A公司以传统的单租户方式构建了如下图结构的供应商管理系统，所有供应商的数据统一存放在一个数据库中其中各数据以供应商编码区分。

 

 

经过产品迭代期和运行期后，A公司的初始设想得以实现，相比之前人工电话、邮件催报等方式效率明显提升，效果也显而易见，但是随着业务的发展，需求的变更，挑战也随之而来，主要体现在以下几个方面：

 

1）业务场景管理冲突

部分供应商需要业务中做系统集成且系统多样，部分供应商由手工采集数据，导致系统无法完全满足所有供应商需求。

 

2）业务关键节点缺失

部分供应商无信息化手段管理关键业务节点，导致A公司无法及时协调供应商间的业务配合，例如，整车外观件间的色差比对、关键结构件间的尺寸比对等。

 

3）业务数据格式多样

供应商信息化建设能力不一，造成同一业务场景中数据输入或输出不同，系统无法进行针对性解决，例如，供应商原材料或成品编码规则不一，系统无法支持物流在线扫码功能。

 

4）业务数据安全风险

供应商、三方物流间业务交织，业务执行过程中的多环节需要配合协调工作，各个环节相互交织成网状，数据权限以及功能权限无法高效实现。

      

当然还有许多由于单租户系统架构导致业务冲突，需求无法快速有效拓展而导致供应链数字化转型未完全达到预期，无法高效响应A公司对产品质量、市场预测、快速交付等核心业务。A公司总结经验教训，重新整合资源，采用多租户架构进一步帮助供应链体系实现数字化转型。

接下来本文对多租户架构及应用场景进行阐述，助力整车企业构建高效、优越、透明、可控的数字化供应链体系。

 

什么是多租户?

多租户（Multi-tenancy）是一种软件架构,它的目的在于将一套应用程序共享给不同的组织(客户)，并且保证各个组织(客户)之间数据的可靠性，安全性以及隔离性。在多租户系统中，我们将这些组织(客户)统称为“租户”。

 

假设现在我们开发了一个新的产品,正在推广，客户A,客户B以及客户C先后下订单购买我们的产品。那么接下来，按照传统的项目实施流程，我们需要分别给A,B,C三个客户分别部署一套独立运行的应用程序，我们称这种方式为单租户模式。

 

 

而在多租户模式下，同样是一套应用程序，针对于客户A,客户B以及客户C，我们会分别为他们创建一个独立运行的租户账号，并且给他们分配不一样的功能及权限。尽管他们使用同一个应用程序，但是他们只被允许访问属于自己的那部分数据。与单租户模式相比,后者在功能扩展和安全控制上更加灵活高效，同事还很大程度地降低了开发和维护成本。

 

 

多租户架构应用场景有哪些？

 

1）应用场景一: 供应链管理(Supply Chain Management)

以整车企业为例, 如果整车企业需要对供应链下游的原料供货商、仓储商、运输商等进行信息化管理,使用多租户系统的好处：

a.各个供应商之间数据隔离,方便维护；

b.整车企业易于统计同类型供应商之间的数据,生成统计报表；

c.投入成本低,不需要给每个供应商部署一套系统,只需要给供应商注册租户账号,然后就可以使用。

 

2）应用场景二: 多组织管理(Multi-Organization Management)

对于集团公司或者跨国企业来说,通常会在各地区划分不同区域,每个区域有不同的子公司.每个公司有着严格的责任区域以及业务划分. 如果将所有的子公司都放在一个系统中进行管理,会存下以下几点问题:

a.权限不易划分： 权限设计时需要考虑跨公司的权限控制，以便每个公司都有一个管理员角色，该角色仅负责维护该公司相关的系统数据；

b.数据过于耦合：不同子公司的各类基础数据耦合在一起，不便处理.业务数据也不方便以公司维度单独进行核算。

 

多租户数据处理方案

多租户系统的健壮与否，最重要的因素之一是要做好数据隔离。关于这一点， 在系统设计之初就需要着重考虑.。多租户数据存储主流的方案主要分为以下三种：

 

1）分离数据库(Separate database)

• 每个租户单独对应一个数据库实例，将不同的租户数据放在不同的数据库实例当中。

 

2）分离Schema(Separate schema)

• 每个租户单独对应同一个数据库实例下面的一个Schema，与分离数据库的区别在于,这种方式只需要安装一个数据库实例。

 

3）数据分区(Partitioned data)

租户共享同一个数据库实例，同一个Schema，但是每张业务表中增加Tenant Identifier字段用于区分不同租户的数据。这种方式隔离级别最低,数据共享程度最高。

 

总的来说，三种方式有利有弊,，需要在共享度、隔离度、复杂度以及成本上进行取舍，鱼和熊掌不可兼得。

 

 

多租户平台设计思路

众所周知，脱离业务的产品框架设计都是耍流氓，好的架构不是设计出来的，而是随着业务发展和客户需求而逐渐演化出来的，所以在多租户产品框架设计时在业务层面需要从以下几个方面来考虑：

 

1）业务划分

根据业务场景和业务功能需求，将产品划分为不同的模块，模块间完全解耦，数据交互时主要采用以下三种方式：

a.消息通讯，建立特定的消息通道，双方监听/生产消息数据。

b.事件总线，建立特定的事件总线，双方监听/生产事件数据。

c.REST服务，需要实时响应的采用REST服务的方式，约定数据格式。

 

2）业务规则

为了适应不同租户对产品的不同业务需求，需要每个模块在提供标准功能外，还需要提供以下功能扩展：

a.功能变种，即产品提供的功能不能完全满足需求，采用参数配置或数据流方向调整来实现功能变形。

b.功能延伸，即租户在现有功能的基础上需要额外的业务，采用消息/事件方式发送新业务请求，在租户的业务规则管理中采用动态脚本的方式建立新的业务点以满足租户需求。

c.功能裂变，即租户对某一个功能在多个维度上都有新的需求，甚至于租户新的需求完全不在现有产品功能列表中，采用模块定制开发热部署的方式进行上线，同时通过License来控制租户的功能模块权限。

 

3）业务引擎

当使用产品的租户变多时，就会面临功能冲突问题，为了在不做定制开发或少做动态脚本配置的前提下满足各客户的需求，采用业务引擎来调度和组合业务规则，完成业务运转。

a.业务节点，业务执行过程中的最小组成单元，进行分类管理，动态组合。

b.业务输入, 业务执行过程中的输入流，进行绑定与监控。

c.业务逻辑，业务计算单元，通过配置四则运算，接口调用，外部脚本处理等进行业务整合。

d.业务输出，业务执行完成后输出结果，进行绑定与监控。

 

4)业务接口

租户集成外部系统串联自己的IT体系。

a.提供标准的业务接口服务，进行租户及用户调用授权。

b.配合外部脚本、规则引擎、消息监听搭建租户特有的接口服务。

c.配合数据流引擎、调度引擎进行外部系统集成。

 

多租户供应链数字化方案落地

PIKE（Polelink Infrastructure Kernel Environment）是北汇自研的一套成熟的软件开发框架，目前已经迭代了三个大的版本。北汇软件开发团队在PIKE 3.0的基础之上，研发出适用上述应用场景的多租户系统平台助力整车厂及其零部件供应商快速构建高效优越的供应链体系，下面附带几张整车企业使用多租户架构的供应链平台基于业务数据进行供应商质量和交付管控的实施效果图，仅供参考：

 

 

 

 

总结

北汇信息深耕智能工厂领域近十年，从MES系统（Manufacturing Execution System,，制造执行系统）逐步开始开发新一代的制造过程管控系统——MOM系统（Manufacturing Operation Management，制造运营管理）。基于多租户（Multi-tenancy）开发架构的应用，北汇信息开发的MOM系统帮助汽车供应商实现数字转型，后续将逐步分享我们在如何快速实现业务、数据可视化、自动化系统集成等方面的经验，敬请期待！