企业做 EHS（健康·安全·环境）系统，风险管控板块不是“多一张表/几条流程”，而是承接识别—评估—巡检—治理—验证这一闭环，并把数据变成可视化、可落地的行动指引。下面这篇文章会从为什么要做、什么是风险管控板块、系统该怎么搭、详细功能、业务流程、开发技巧、代码参考到实现效果与常见问答，全方位覆盖。目标是能让技术团队和EHS负责人在看完后：知道要做什么、怎么做、代码怎么接入、效果怎么评估。
本文你将了解
- 为什么要讲 EHS 风险管控板块？
- 什么是 EHS 风险管控板块
- 整体架构（含架构图）
- 风险识别与评估（含 LEC 标准说明与示例）
- 风险巡检任务（数据流与流程图）
- 风险管控看板（指标、热力图、趋势分析）
- 主要功能模块详解
- 开发技巧与落地建议（性能、安全、权限、数据质量、上手优先级）
- 实现效果（KPI、预期收益、案例性指标）
- 代码参考（数据库建表、后端 API、LEC 算法实现、前端看板示例）
- FAQ
注：本文示例所用方案模板：简道云EHS健康安全环境管理系统，给大家示例的是一些通用的功能和模块，都是支持自定义修改的，你可以根据自己的需求修改里面的功能。
一、为什么要讲 EHS 风险管控板块？
许多企业有事故隐患、违规操作的痛点：日常巡检记录成表格堆在盘上、风险评分靠人工经验、整改闭环不及时、看板信息滞后。风险管控板块的核心价值就在于把“隐患和风险”转成可量化、可追溯、能驱动动作的业务对象（risk），并通过巡检、告警、任务驱动整改，最终通过数据证明风险下降。对企业来说直接收益有：事故率下降、合规通过率上升、保险/赔付成本下降、管理审计效率提升。
二、什么是 EHS 风险管控板块（功能边界与核心能力）
风险管控板块专注于以下能力：
- 风险识别（来自巡检、报告、设备监测、上报）
- 风险评估（LEC/矩阵打分，自动或人工）
- 风险分级与优先级排序（高、中、低）
- 巡检/整改任务下发与闭环验证（移动端采集）
- 风险缓控措施管理（SOP、责任人、时限）
- 风险看板与分析（热力图、趋势、责任到人）
- 与其它 EHS 板块联动（事故管理、培训、许可管理）
简而言之，风险管控是“把隐患从发现到最终验证消除”的闭环管理系统。
三、整体架构（含架构图）
下面给出一个典型的三层架构（文本版架构图）：
rust
[移动端/巡检App] <---> [API 网关] <---> [后端服务群]
| 上传图片/视频 | 认证/限流 | Risk Service (Node)
| 离线缓存/同步 | 路由 | Inspection Service (Python)
| 短息/推送 | 日志/审计 | Auth Service (JWT)
<--> 数据库(Postgres)
<--> 时序DB（Prometheus/Influx）用于监控传感器
<--> 文件存储(S3)
<--> BI/ELK（ES）用于报表/全文检索
- API 网关统一做鉴权、配额、版本控制。
- 后端按业务拆微服务：risk、inspection、task、report、user。
- 数据库以关系型为主（风险/任务/用户/审批），时序或大数据用于传感器/趋势分析，文件存储用于图片证据。
四、风险识别与评估（含 LEC 标准说明与示例）
1.什么是 LEC？
LEC 是一种常用的风险评估方法，三个维度：
- L — Likelihood（发生概率 / 可能性），通常 1-5 评分
- E — Exposure（暴露度 / 接触频率），表示有多少人/频次接触到风险 1-5
- C — Consequence（后果严重性），事故后果的严重程度 1-5
风险得分 = L × E × C（或可采用加权和），常映射为风险等级：
- 1–20 低风险（绿色）
- 21–60 中风险（黄色）
- 61–125 高风险（红色）
示例：电缆裸露（L=3, E=4, C=4） => 分数 48 => 中风险，需要整改并跟踪。
2.在系统中如何实现 LEC
- 提供一套标准化的量表供评分，并允许配置（公司可调权重）
- 评分既可由巡检人员现场评分，也可由系统在规则触发时自动初评（例如传感器报警触发高 C）
- 保留评分历史（用于趋势、验证评估是否下降）
五、风险巡检任务（数据流与流程图）
巡检任务的数据流（文本版流程图）：
arduino
触发来源（定期计划 / 上报 / 传感器）
↓
系统生成巡检任务（Task）
↓
下发到巡检人员手机（含表单、拍照、定位）
↓
巡检人员现场采集（图/视频/语音/勾选）
↓
若发现隐患 => 生成风险记录（Risk），并关联现场证据
↓
自动或人工 LEC 评估 => 风险等级确定
↓
系统根据策略生成整改任务并分派责任人
↓
责任人整改并上传证据
↓安全主管复核并关闭或再次评估
数据要点：
- 每个动作都要有时间戳、经纬度、媒体证据与操作人（便于追溯）
- 支持离线采集与断点同步（移动端必备）
六、风险管控看板（指标、热力图、趋势分析）
看板最核心的 6 个视图：
- 风险热力图（按区域/车间/设备）
- 风险等级分布（高/中/低）与趋势图（周/月）
- 未关闭高风险列表（优先级队列）
- 巡检完成率与整改超期率
- 风险来源占比（巡检/上报/传感器）
- 指标卡（近 30 天事故率、隐患数、平均关闭时长）
视觉提示：
- 热力图用二维坐标（位置×风险等级）或车间树状结构。
- 趋势与对比能反映整改效果（风险得分是否下降）。
七、主要功能模块详解（含 DB 与接口设计示例）
1.数据库核心表（示例 PostgreSQL）
sql
-- users
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username VARCHAR(64) UNIQUE NOT NULL,
name VARCHAR(128),
role VARCHAR(32),
phone VARCHAR(32),
created_at TIMESTAMP DEFAULT now()
);
-- risks
CREATE TABLE risks (
id SERIAL PRIMARY KEY,
title VARCHAR(255) NOT NULL,
description TEXT,
location VARCHAR(255),
source VARCHAR(64), -- inspection/report/sensor
l INT, e INT, c INT,
score INT,
level VARCHAR(16), -- low/medium/high
status VARCHAR(32) DEFAULT 'open', -- open/in-progress/verified/closed
created_by INT REFERENCES users(id),
created_at TIMESTAMP DEFAULT now()
);
-- tasks (for inspections/rectifications)
CREATE TABLE tasks (
id SERIAL PRIMARY KEY,
risk_id INT REFERENCES risks(id),
assignee INT REFERENCES users(id),
type VARCHAR(32), -- inspection/rectify/review
due_date DATE,
status VARCHAR(32) DEFAULT 'pending',
evidence JSONB, -- links to S3
created_at TIMESTAMP DEFAULT now()
);
-- inspections
CREATE TABLE inspections (
id SERIAL PRIMARY KEY,
task_id INT REFERENCES tasks(id),
inspector INT REFERENCES users(id),
result JSONB,
location GEOGRAPHY(Point,4326),
photos JSONB,
created_at TIMESTAMP DEFAULT now()
);
2.后端 API（Node.js + Express 简要示例）
js
// app.js (Express)
const express = require('express');
const bodyParser = require('body-parser');
const { pool } = require('./db'); // pg pool
const app = express();
app.use(bodyParser.json());
// 创建风险（来自巡检或上报）
app.post('/api/risks', async (req, res) => {
const { title, description, location, l, e, c, created_by, source } = req.body;
const score = l * e * c;
const level = score >= 61 ? 'high' : (score >= 21 ? 'medium' : 'low');
const result = await pool.query(
`INSERT INTO risks (title, description, location, l, e, c, score, level, created_by, source)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10) RETURNING *`,
[title, description, location, l, e, c, score, level, created_by, source]
);
// 根据level触发任务创建逻辑（省略）
res.json(result.rows[0]);
});
// 根据规则创建整改任务（伪代码）
app.post('/api/tasks/generate', async (req, res) => {
const { risk_id } = req.body;
// 根据 risk.level 查找责任部门与默认时限，生成 task
// ...
res.json({ ok: true });
});
app.listen(3000, ()=>console.log('API listening 3000'));
3.LEC 风险评估的可扩展实现（示例 Python）
python
def lec_score(l, e, c, weights=(1,1,1)):
# 支持自定义权重与映射
wL, wE, wC = weights
score = int(round((l * wL) * (e * wE) * (c * wC)))
# 映射等级
if score >= 61:
level = 'high'
elif score >= 21:
level = 'medium'
else:
level = 'low'
return score, level
4.巡检移动端数据采集（关键点）
- 表单模板动态下发（不同岗位不同表单）
- 支持拍照/视频/录音 + 自动定位 + 离线缓存 + 图片压缩
- 必须上传证据并生成缩略图以节约流量
- 每次采集要记录 GPS 与时间戳，防止伪造
5.风险管控看板前端（React + Recharts 示例片段）
jsx
import React, { useEffect, useState } from 'react';
import axios from 'axios';
import { ResponsiveContainer, BarChart, Bar, XAxis, YAxis, Tooltip } from 'recharts';
export default function RiskLevelChart() {
const [data, setData] = useState([]);
useEffect(()=> {
axios.get('/api/dashboard/risk-levels').then(r=>setData(r.data));
},[]);
return (
风险等级分布（近30天）
);
}
八、开发技巧与落地建议（实用清单）
- 优先 MVP： 先做“风险登记—LEC 评估—自动生成整改任务—整改闭环”的最小可用闭环，再迭代看板与高级分析。
- 证据驱动：所有重要动作必须有图/视频/定位/时间戳，才能在审核/事故时有凭据。
- 权限与审批流： 分层权限（操作用户、责任人、安全主管、EHS 管理员），敏感操作（关闭高风险）必须复核。
- 规则引擎：风险评分与任务优先规则要做成可配置（非硬编码），方便根据法规或企业要求调整。
- 离线优先：移动端巡检支持离线，网络恢复后自动同步并保证幂等性（事务 ID）。
- 数据质量：建立数据校验与重复检测（例如同一位置同一问题重复上报自动合并或关联）。
- 监控与告警：对关键 API、任务超期率、同步失败率做监控，并把关键告警推送到微信/钉钉/短信。
- 可扩展的分析层：把历史评分、整改时效入 ELK 或 BI，以便做根因分析与预测性维护。
- 隐私与合规：保留用户操作日志，严格控制谁能查看图片证据，数据加密、备份策略。
- 上手建议：先把 10 类常见风险做成标准模板（电气、机械、化学、高处、动火、受限空间等），把公司常见过程覆盖到模板里，能快速落地。
九、实现效果（KPI、预期收益）
落地后可以衡量的关键 KPI：
- 高风险隐患数（30天）下降比例
- 隐患平均关闭时长（从发现到关闭）
- 巡检完成率和整改超期率
- 事故/轻伤事件率下降（长期）
- 审计合规通过率
预期举例：企业若能把高风险隐患平均关闭时长从 15 天降到 5 天，事故率通常有显著下降（具体效果视行业而定）。
十、代码参考（整合示例）
以下为整合性的简化实现示例，涵盖创建风险、LEC 评分、自动生成整改任务的核心逻辑（伪生产级，供参考）。
js
// core.js (伪代码)
const { pool } = require('./db');
async function createRisk(payload) {
const { title, desc, location, l, e, c, created_by, source } = payload;
const score = l * e * c;
const level = score >= 61 ? 'high' : (score >= 21 ? 'medium' : 'low');
await pool.query('BEGIN');
try {
const res = await pool.query(
`INSERT INTO risks (title, description, location, l, e, c, score, level, created_by, source)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10) RETURNING *`,
[title, desc, location, l, e, c, score, level, created_by, source]
);
const risk = res.rows[0];
// 自动生成整改任务策略（示例）
let dueDays = level === 'high' ? 3 : (level === 'medium' ? 14 : 30);
// 根据 location / risk type 查找默认责任人（伪）
const assignee = await lookupAssignee(location);
await pool.query(
`INSERT INTO tasks (risk_id, assignee, type, due_date, status, created_at)
VALUES ($1,$2,$3,$4,$5, now())`,
[risk.id, assignee, 'rectify', new Date(Date.now()+dueDays*24*3600*1000), 'pending']
);
await pool.query('COMMIT');
return risk;
} catch(e) {
await pool.query('ROLLBACK');
throw e;
}
}
十一、FAQ
Q1：LEC 风险评分方法是否适合所有行业？如何校准权重？
LEC 是一种通用且直观的评价方式，但不一定适合所有行业的细节需求。不同企业面临的风险场景、人员暴露程度和后果敏感性不一样，因此建议在系统上线前做一次“标定”工作：组织 EHS 专家、生产负责人、工艺专家对若干典型隐患进行评分，收集他们的 L、E、C 原始评分，并计算出在该企业实际场景下的分数分布。基于分布可以决定是否使用乘法（L×E×C）或加权和形式（w1×L + w2×E + w3×C），以及是否调整分级阈值（例如高风险设为 >80）。此外应把权重和阈值做成配置项，方便在法规变化或经验积累后调整。标定后持续观察 3-6 个月，验证评分与实际事故/险情的相关性，必要时再迭代。
Q2：移动端巡检如何保证采集数据的真实性（避免假打卡或伪造图片）？
要保证数据真实性，技术与管理要结合。技术上建议启用定位与时间戳强校验（照片 EXIF + GPS），同时上传多张照片并要求照片包含当前工位的特征（如设备铭牌），或要求拍摄包含操作人员的半身照作为佐证（注意隐私合规）。支持离线采集后同步时，严格验证同步时间和本地操作历史（例如对比本地时间与服务器时间）。可以结合信任链：每条记录生成唯一的不可篡改 ID，并把关键事件摘要写入审计日志或使用不可变的存储（例如 append-only log）。管理上则通过随机抽检、复核和处罚规则来减少造假动力：例如对关键高风险巡检实行专人复核，复核不通过则要求重新整改并记录责任。结合技术（定位、证据）与管理（责任、审计），能大幅提高数据可信度。
Q3：如何把风险管控系统与现有的 ERP / MES / SCADA 等系统对接？
对接要分层次进行：首先识别对接需求（是单向推送报警，还是双向同步任务/状态）。常见做法是通过中间层（API 网关或消息队列）完成数据交换。对于实时性要求高的场景（如 SCADA 传感器触发高 C），建议使用消息总线（Kafka 或 MQTT）把报警事件推给 risk service 进行初评与任务生成。对于 ERP/MES 的工单或责任人信息，可通过 REST API 定期同步组织结构、设备资产清单与责任人映射表，以便自动分派任务。重要的设计原则：保证幂等（重复消息不会生成重复任务）、做好权限与数据字段映射、记录每次对接变更的审计日志。实施时先做小范围试点（单一生产线或单一设备类型），验证端到端流程后再逐步扩大对接范围，减少集成风险。
