智能电厂管理与生产业务后台

这是什么

把运行、检修、计划的单据和流程收进管理后台，不重做现场控制系统。

当时卡在哪

运行、检修、计划各拿各的表和聊天记录对账。现场已经有系统在控机组——后台如果再做成第二套控制，现场不会用；如果不先画清谁发起、谁审批、谁对账，单据只会继续散在表格里。

做了什么

• 以平台框架约束共性（权限、流程、主数据），用配置表达各厂或各专业差异。
• 业务流程先于功能清单：能画清链路，才拆页面与接口。

业务链路（脱敏）

仅使用已确认口径：近两年国企侧智能电厂，工作是管理与生产业务后台的平台框架和流程设计。未编造内部架构图、系统清单与资源规格。

1. 1

   角色与链路

   先识别运行、检修、计划等角色，把发起—审批—执行—回写画清楚。

2. 2

   主数据与单据

   设备/组织/权限等主数据与工单类单据分开，避免「一张表既当档案又当流程」。

3. 3

   可配置流程

   把节点、输入输出和权限收成可调整的流程，而不是为每个厂写死一套页面。

4. 4

   对接现场系统

   管理后台消费或回写既有生产/管理域，不替代现场控制。

结果

能画出谁发起、谁审批、谁执行；后台不接管机组。公开的公司名和数字以后补。

• 形成可对外讲述的工作边界：智能电厂的管理与生产后台，走「框架 + 流程 + 集成」，而不是堆功能。可公开的主体名称与量化结果待补充。

和研发怎么对齐

这类后台和技术方案的对齐方式，与汽车配置/变更平台同类：先域后服务。电厂现场已有生产系统，管理后台是协同与单据层，不是第二套 DCS。

当时的判断： 后台别去替代现场

附录

负责管理与生产业务后台的平台框架和业务流程设计：划清域与角色、定义主数据与单据、把可配置的流程从一次性线下协同里拆出来。具体主体名称、内部系统清单与未公开指标此处不写。

我负责的边界

• 电厂管理与生产业务的后台：角色、权限、流程节点、主数据与单据，以及和既有生产/管理域的对接边界。
• 平台框架：哪些能力是可复用模块（组织权限、流程、主数据），哪些是电厂场景配置。

明确不负责

• 机组控制、保护与现场实时控制（属生产控制系统，不在管理后台里重写）。
• 未对外公开的电厂主体全称、内部账号级联调与敏感运行指标。

协作方式

• 业务：和运行、检修、计划等角色把「现在怎么协同」画成可配置流程。
• 研发：对齐域边界、主数据与集成方式；非功能需求（权限、审计、容量量级）由产品提出，选型与规格由研发定。

分层怎么说（不写选型）

• 访问层：管理后台或门户，按角色做权限与菜单，而不是一套界面打天下。
• 应用层：按业务域拆模块（主数据、流程、规则、单据），先定域边界再谈服务怎么拆。
• 数据层：主数据与业务单据分开，加上审计与日志，保证可追溯、可对账。
• 集成层：对接已有 ERP / MES / 生产或交易系统，而不是重写现场控制或核心账务。

独立部署时怎么估资源

独立部署一个管理或生产后台模块时，产品侧用下面的方法给量级，不在未确认前写核数与内存。

• 无状态应用：按管理端人数与峰值并发估实例，可水平扩；先问「同时在用的人」而不是先问机器型号。
• 数据库：按单据量、查询是否拖垮写入来决定要不要读写分离或把报表拆出去。
• 文件与日志：附件、导出、审计不宜和业务库绑死，独立存储更利于容量与合规。
• 一个可独立部署的中等管理模块，通常是「应用实例 + 库 + 必要中间件」；主路径模块和边缘模块的容量差一档。具体核数内存由研发按压测定，产品给出可用性、权限、审计和量级。