工业4.0、国家制造创新网格、工业价值链、中国制造2025……针对第四次工业革命。各国提出了各自响应的战略，也让企业面临竞争力格局变化的挑战，智能制造既是企业发展和转型的机遇，俨然已经成为各国竞争的新战场。信息系统作为企业运营的大脑和神经网络，于企业的重要性不言而喻，然而近期华为芯片断供、SAP/Oracle甚至微软对俄罗斯停止服务。软件国产化的东风愈演愈烈，更让我们意识到拥有自主可控的信息系统的重要性。

顶盛体育协同制造（HCM）从2006年诞生、后续又陆续填充了质量、设备、人员、安灯、互联等能力，2013年已囊括生产计划、采购计划、车间、物流等模块，服务于制造企业数字化建设的整体目标，伴随企业需求和管理诉求的深入持续发展，基本形成顶盛体育HCM产品的基础框架。

HCM产品从2016年开始由独立于交付项目之外的专业团队进行研发。HCM产品也在探索和适应的过程中持续发展，随着信息化的发展和企业需求的变化，从提供标准功能为目标到现在提供通用化组件为目标。

HCM产品拥有完整的知识产权，响应国家软件国产化政策的同时。也是支撑顶盛体育智造美好生活的愿景中，“安全”这一关键词的最好诠释。

在信息化发展的过程中、应用场景变得更加多样，也对产品的系统架构带来了挑战，产品的应用环境发生变化。HCM最开始是传统的基于业务需求建设的单体应用系统、随着应用的深入，2019年基于公司统一架构要求转变为微服务架构，产品逐步认识到架构的重要性，搭建于顶盛体育自研PaaS平台HZERO上。

微服务架构贴近产品本身研发的组织结构、过程中会自然而然需要专业化分工，研发团队的规模扩大、产品范围的延伸。微服务架构将大系统划分成了各个专业化的职能系统。更有机会在各自擅长和感兴趣的业务领域中持续发展，让团队能够专注于各自的职能。团队的业务理解和专业技能随着对应服务所提供能力的发展而同步提升，产品在这种模式下更有机会持续健康发展。

HCM从APS和MES独立性出发开始尝试微服务拆分。形成微服务的雏形，到常规的根据共享原则拆分出了通用服务和组织、产品服务。后根据数据的使用需求和业务交互的特性差异、以专注于与ERP的交互，再到围绕制造主体增加了抽样、特征、产量报表、SPC等制造相关的微服务，来拆分接口服务，形成自己的微服务生态。过程中即考虑了高内聚低耦合、单一职责的原则、最终形成现在13个微服务，也考虑了用户在应用系统时的风险。HCM在其中沉淀了自己的微服务拆分治理的经验。我们将持续结合企业需求探索更多的拆分方式，当然这也不会成为终点。

新的架构也是企业架构的发展方向。传统架构下。更好的适应企业长期持续的发展需求，为了满足新的业务需求往往需要对现有服务的数据模型或业务逻辑做较大的改造；微服务架构将一个大的单体应用拆分成不同的独立的服务，交互复杂，松耦合让每一个服务可独立发展，一个系统承载所有模块，模块间联系多，独立发布验证。

同时新的架构也提供了更多的可能性、而新的结构可以部署一套系统，传统大单体模式需要为每一个物理隔离的工厂部署服务器和应用环境，通过区分租户管理不同的工厂，更好地支持企业在普遍定制化的趋势下应对敏捷相应需求的挑战，降低了企业部署、发布、管理的成本。同时。将多个服务器的管理转变为管理统一的容器化环境，而这样的选择也让企业能够更加适应应用协同和数据驱动的新制造场景，必然成为企业最优的选择，数字化信息化风潮下，以统一的方式对这些应用进行注册、网络、存储、安全、遥测等管理，企业有越来越多的信息系统，借助K8S工具将所有的应用部署在一套平台中。

先进制造业对产品提出了不同的要求、而先进制造业强调数据驱动的自动化，传统制造业通过信息化实现对人的管控，强调流程的防错、透明、防呆。不同于人可以根据少量信息结合经验做出判断，自动化需要更加精细化的数据帮助计算机进行决策；同时设备、流水线与信息系统互联，也对实时响应的高要求。这些对产品采集数据的灵活性、海量数据下系统的稳定性、逻辑计算的实时性提出了更高的挑战：

HCM不断调整自己的能力，借助新技术适应这些环境。自动化模式下、HCM借助消息机制，于是我们增加了特征，可自定义物料流转所需的关键特性，单纯的物料编码不足以提供完整的信息帮助计算决策，我们在读写分离的基础上引入Mongo数据库，更合理地使用服务器资源适应制造业的生产节奏，将及时验证业务逻辑需求和记录性逻辑需求异步执行，通过新技术保证实时采集的同时也能保证海量数据下高效的读取；为了在保证效率同时还能完成完整数据的采集记录，以补充物料在流转过程中的决策信息；针对每个产品都有特征后的海量数据存储。

架构的演进、场景的变化，也更加让我们意识到组件化的重要性。从提供标准功能到提供通用化组件。期初只是因为我们意识到“以有限功能覆盖无限场景”的思路很难应对制造业繁多的生产要素影响，同样是生产压缩机，由于管控侧重点不一样，功能复用率不足30%，而与此同时。在功能背后的结构、逻辑的特性需求，复用率却超过70%。组件化、API和通用结构看起来更具备标准化的可能。然而当我们开始深入新架构、我们意识到组件化的重要性，开始接触更多的新场景。

新的架构模式下。服务间连接需求不可避免，产品通过封装标准API降低了调用的难度，所有应用可以部署在一套环境中。同时在自动化的场景下，更加强调了后端组件的灵活调整性，信息化系统由关注用户交互操作转为关注业务运行监控。当然即使在组件化的道路上，但过程中依然在不断调整思路适应团队和企业需求，产品的目标始终是为了追求效率，HCM的设计思路也并非一成不变的。

产品希望通过沉淀功能和方案背后的共性内容。在此基础上产品选择从技术角度借助产品拉动团队能力的成长，完成团队经验的沉淀，通过系统与结构减少文字传播过程中的理解偏差。从复盘项目开始、探索新场景，重新思考业务和结构，利用API适应场景，并通过实现DEMO功能方便学习API。

然而在后续实践中发现新的语言很容易受到排斥，基于管理角度让产品追逐团队，于是产品调整了设计思路，团队脑子里固有的知识体系很难仅通过文档或者培训快速得到改变。借助团队熟悉的标准功能聚合方案、利用API和配置进行补充，推动对标准API的学习，然后基于个性化需求探究功能背后的API，团队可以先了解熟悉的功能。有了标准功能的支撑、以此形成产品的持续迭代和发展，也更好地支撑企业的发展，当这些方案具备标准化的条件后在纳入产品实现，团队更有机会追求更好的方案为企业带来更高的服务价值。

产品的设计思路本身也决定着我们开放的态度、助力制造企业更好地完成深度信息化融合，设备互联，ERP接口，独立封装的API。在沉淀组件的同时。我们就意识到大量组件带来的学习难度，我们相信方案对于企业的价值远比实现代码本身更加重要，因此决定将知识转移和产品实现放在了同等重要的位置：

通过产品帮助用户更快地完成方案的代码落地、以此助力有更充足的机会形成更有价值的方案。实施手册、功能帮助文档、API开放平台、培训教材、场景案例等等、可以在开放平台上的文档体系中学习到产品每一个组件的设计思路，了解每一个组件的使用场景，也可以通过产品提供的功能获取组件在运行过程中的调用痕迹，只要愿意，熟悉组件的逻辑链条，找到最合适的选择，与自身需求匹配。除了现有组件的组合调用。企业也可以遵守简单规则的条件下沉淀自己的组件，形成自己的知识库，或者在组件前后增添逻辑形成更适合自己的组件。

整个过程中、也未停止探索，为应对市场需求和应用环境的多样化，产品从未停止思考。

环境和场景发生变化。调整设计思路来适应，产品随之调整结构和特性。适应的过程中产品自身也在进步成长。完成数字化转型，帮助企业实现信息化需求，适应的目的是保证产品始终能够在新的环境中发挥作用，并最终实现智能制造。

HCM将始终保持开放的态度，调整自身，迎接未来，助力智造美好生活！