企业做 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 定期同步组织结构、设备资产清单与责任人映射表,以便自动分派任务。重要的设计原则:保证幂等(重复消息不会生成重复任务)、做好权限与数据字段映射、记录每次对接变更的审计日志。实施时先做小范围试点(单一生产线或单一设备类型),验证端到端流程后再逐步扩大对接范围,减少集成风险。