764 lines
55 KiB
Markdown
764 lines
55 KiB
Markdown
# 滨化集团智慧招标平台（STP）用户需求分析说明书
|
||
|
||
**版本：** V1.4
|
||
**编制日期：** 2026年6月25日
|
||
**编制依据：**
|
||
- 《招标管理制度》（2026年4月版）
|
||
- 《招标评委管理规定》（2026年4月版）
|
||
- 《8.4.4.1 招标供应商长短名单管理流程》
|
||
- 《8.4.4.2 招标委托流程》
|
||
- 《8.4.4.3 招标立项流程》
|
||
- 《8.4.4.4 开标及评标流程》
|
||
- 《8.4.4.5 定标流程》
|
||
- 《8.4.4.6 投标保证金管理流程》
|
||
|
||
---
|
||
|
||
## 第一章 项目概述
|
||
|
||
### 1.1 建设目标
|
||
建设一个**AI原生、全流程线上闭环、主动式智能**的招标平台，覆盖公开招标、邀请招标、竞争性谈判、单一来源等采购方式，实现从需求提报到合同归档的全生命周期数字化、智能化管理，显著提升效率、降低风险、优化供应链生态。
|
||
|
||
### 1.2 业务范围
|
||
- **适用对象**：集团公司及下属全资子公司和控股公司
|
||
- **适用采购类型**：工程、货物、服务
|
||
- **招标门槛**：工程/货物类单项/框架年度估算 ≥50万元；服务类 ≥30万元
|
||
- **谈判管理**：30万元及以上服务类采购（独家/单一/竞争性谈判）
|
||
|
||
### 1.3 核心业务变革点
|
||
|
||
| 旧流程痛点 | 新流程解决方案 |
|
||
| :----------------- | :------------------------------ |
|
||
| 公开招标线下报名、邮件投标，数据割裂 | **招标门户+在线加密投标**，全流程线上闭环 |
|
||
| 供应商与专家库封闭，资源难以沉淀 | **AI 自主寻源+AI资格审核**，自动入库形成潜在资源池 |
|
||
| 资质审核、雷同检测、价格分析全靠人工 | **AI自动完成**，人类转为复核与决策 |
|
||
| 系统间割裂，需手动对账、补录 | 与**OA/财务/SAP/档案**等系统深度集成，数据自动流转 |
|
||
| 传统菜单式界面，学习成本高 | **角色化智能工作台+智能助手“小滨”**，事找人 |
|
||
|
||
---
|
||
|
||
## 第二章 用户角色与职责矩阵
|
||
|
||
| 角色 | 主要职责 | 关键操作 | 关联制度/流程 |
|
||
| :--------------- | :------------ | :-------------------------- | :------------------- |
|
||
| **需求部门人员** | 发起采购需求，提供技术规格 | 自然语言描述需求、确认委托单、参与技术标评审 | 《招标管理制度》5.3 |
|
||
| **招标专员** | 策划与执行招标全流程 | 确认AI寻源、编辑招标文件、组织评审、发起审批 | 《招标管理制度》4.1；各流程文件 |
|
||
| **采购执行部门（采购专员）** | 整合计划、签订合同 | 提报委托、确认中标结果、执行合同、收取履约/质量保证金 | 《招标管理制度》4.2；《定标流程》 |
|
||
| **评标专家（内/外）** | 独立、公正评审 | 在线盲评、打分、签署《评标纪律承诺书》、回避申报 | 《评委管理规定》4.6/4.7/4.8 |
|
||
| **评标委员会工作领导小组** | 重大事项决策 | 审批废标、处理异常、审批特殊评标情况 | 《评委管理规定》4.1.2 |
|
||
| **审批人（各级领导）** | 线上审批关键节点 | 审批委托/立项/公告/定标等 | 《招标管理制度》5.5/5.8/5.11 |
|
||
| **供应商** | 参与投标 | 注册、报名、缴费、加密投标、接收结果 | 《招标管理制度》5.9/5.10 |
|
||
| **系统管理员** | 平台运维、权限配置 | 用户管理、流程配置、接口监控 | - |
|
||
| **合规/审计** | 监督、审计 | 查看审计轨迹、围串标报告 | 《招标管理制度》5.17 |
|
||
|
||
---
|
||
|
||
## 第三章 详细业务流程
|
||
|
||
本章按招标全生命周期分解为6个主阶段。全景流程图如下：
|
||
|
||
```mermaid
|
||
graph TD
|
||
Start((开始))-->A[[8.4.4.2招标委托流程]]
|
||
subgraph H [寻源与立项]
|
||
B[[8.4.4.1供应商寻源流程]] -.-> C[[8.4.4.3招标立项流程]]
|
||
end
|
||
A-->H
|
||
H-->D[[8.4.4.4开标及评标流程]]
|
||
D-->E[[8.4.4.5定标流程]]
|
||
E-->|资料转交|G[[SRM平台]]
|
||
E-->F[[8.4.4.6投标保证金管理流程]]
|
||
F-->End([结束])
|
||
```
|
||
*说明：供应商寻源流程与招标立项流程可能并行展开，招标立项是关键流程，立项后方能进入开标与评标流程。*
|
||
|
||
### 3.1 阶段一：需求与委托
|
||
|
||
- **对应流程文件**：`8.4.4.2 招标委托流程`
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A([采购人员登录]) --> B1[选择采购计划<br>（从SRM读取，可跳过）]
|
||
B1 --> C[向“小滨”描述需求] --> E[AI解析并预填委托单]
|
||
B1 -->|手动| D[进入委托表单]
|
||
E --> F[需求人员确认/修改]
|
||
D --> F
|
||
|
||
F --> H[推送OA审批]
|
||
H --> I{审批结果}
|
||
I -->|通过| J([委托流程通过])
|
||
I -->|驳回| F
|
||
|
||
Sendback[下级流程退回]-.->F
|
||
|
||
subgraph SA[备注]
|
||
Remark["当招标委托为邀请招标时，采购人员须从供应商库中选择供应商名单（AI辅助）"]
|
||
end
|
||
```
|
||
|
||
#### 关键表单
|
||
- **《招标委托表》**（分货物类 BH-SCM-JL-008、工程类 BH-SCM-JL-009、服务类 BH-SCM-JL-010）
|
||
- **核心元素**：项目名称、标的数量、预算/估算金额（含税）、费用来源（大修/技改/项目/其他）、招标方式（公开/邀请）、付款方式、交货期/工期、立项审批情况、技术要求、技术评标办法、投标单位资格要求、合同模板、**邀请招标推荐单位（不少于3家）**。
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||
| **触发条件** | 采购计划已下达，或紧急需求获口头批准。 |
|
||
| **登录** | 本系统登录与 IAM 对接，实现单点登录。 |
|
||
| **输入** | 自然语言描述 / 历史同类项目 / 立项文件。 |
|
||
| **输出** | 结构化《招标委托表》。 |
|
||
| **角色操作** | - **需求部门**：提出采购计划。<br>- **采购人员**：审核及补充委托资料。<br>- **需求人员**：确认AI预填单。<br>- **需求部门负责人**：组织内部评审（此为非OA的必要评审，确定技术参数和预算）。<br>- **OA审批人**：二级部门负责人（采购部/相关部长）审核。<br>- **AI“小滨”**：提取关键信息、预填表单。 |
|
||
| **业务规则** | - 委托单核心元素必须完整（制度5.3.2）。 |
|
||
| **采购计划** | ==不直接从 SAP 读取，通过 SRM API 读取。== |
|
||
| **异常处理** | - 驳回：记录原因，退回修改。<br>- 超时未批：系统自动催办（24h/48h）。<br>- 撤回：需求人员因其它原因撤回委托（已通过审批并进入下一流程的无法退回）。 |
|
||
| **AI介入** | - 自然语言解析并智能预填委托单。<br>- 自动判断是否需招标（对照5.1.3门槛）。<br>- 推荐预算参考与历史中标价。 |
|
||
|
||
---
|
||
|
||
### 3.2 阶段二：供应商寻源
|
||
|
||
- **对应流程文件**：`8.4.4.1 招标供应商长短名单管理流程`（版本1.1）
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
Start([招标委托流程通过]) --> Branch{招标方式}
|
||
|
||
Branch -->|邀请招标| Invite[邀请招标分支]
|
||
Branch -->|公开招标| Public[公开招标分支]
|
||
|
||
subgraph Invite [直接读取采购员提供的供应商名单]
|
||
end
|
||
|
||
subgraph Public [公开招标分支]
|
||
B0[AI生成寻源公告] --> B1[修改确认寻源公告]
|
||
B1 --> B2{组织评审寻源公告}
|
||
B2 -->|未通过|B1
|
||
B2 -->|通过|B3{审批}
|
||
B3 -->|驳回|B1
|
||
B3 -->|通过|B4[发布寻源公告]
|
||
B4-->C1[[AI智慧寻源]]
|
||
C1-->B5["供应商报名<br>(平台注册/提交资质材料)"]
|
||
B5 --> E1["供应商自动入库<br>(本地供应商池)"]
|
||
E1 --> B6[[AI辅助供应商审核筛选<br>（资质/风险/关联关系）]]
|
||
B6 --> B7[组织评审]
|
||
B7 --> B8[形成报名通过单位名单]
|
||
B8 --> B9[接收短名单<br>（即报名通过名单）]
|
||
B8 -.->|并行| B10[[库外供应商SRM入库]]
|
||
end
|
||
|
||
Invite --> End([输出短名单，进入后续招标环节])
|
||
B9 --> End
|
||
```
|
||
|
||
#### 关键表单
|
||
| 表单名称 | 产生环节 | 核心元素 | 备注 |
|
||
| :----------- | :------------ | :--------------------------- | :----- |
|
||
| **供应商长名单** | 活动030 | 供应商名称、联系人、推荐部门、初步评审意见、资质概况 | 邀请招标专用 |
|
||
| **供应商短名单** | 活动050 / 活动120 | 最终入围供应商名单、评审结论、是否在库内 | |
|
||
| **寻源报名公告** | 活动060 | 项目概述、报名资格要求、技术要求、报名资料清单、截止时间 | 公开招标专用 |
|
||
| **报名通过单位名单** | 活动110 | 通过审核的供应商名称、审核意见、风险等级 | 公开招标专用 |
|
||
|
||
#### 流程活动详细说明
|
||
|
||
| 活动名称 | 活动描述 | 角色 | 输入 | 输出 |
|
||
| :--------------- | :----------------------------------------------------------------------------------------------------------------------------- | :----- | :------------------ | :------------- |
|
||
| **形成短名单** | 对评审通过的供应商推荐为本次招标拟邀请单位，形成最终短名单。若供应商不在合格供方库内，则触发供应商注册/认证流程。 | 相关部门人员 | 评审结论 | **《供应商短名单》** |
|
||
| **编制寻源报名公告** | 招标管理部根据招标委托编制公开寻源报名公告，明确报名资格、技术要求等。 | 招标人员 | 招标委托 | 《寻源报名公告》草案 |
|
||
| **组织评审寻源公告** | 组织需求、采购等部门对报名公告进行评审。 | 相关部门人员 | 《寻源报名公告》草案 | 评审意见 |
|
||
| **审批** | 对寻源公告进行审批。 | 审批人 | 评审后的公告 | 审批通过的公告 |
|
||
| **发布寻源公告** | 在招标门户、行业平台等渠道发布公告。 | 招标人员 | 审批通过的公告 | 已发布公告 |
|
||
| **AI 智慧寻源** | ==AI 通过SRM库、本平台供应商池、互联网平台（须维护信任平台列表）查找相关的信息，找到优质供应商，并主动向其发送邀请报名的信息（电子邮件等），同时会将寻源结果**向招标专员、供应商管理专员**反馈。(反馈之后经供应商管理专员确认，必须加回执)== | AI | 采购需求、审批通过的公告 | 主动发邀请邮件，AI寻源结果 |
|
||
| **接收供应商报名资料** | 接收供应商在线提交的报名资料（资质、业绩等）。 | 招标人员 | 供应商报名信息 | 报名单位清单 |
|
||
| **AI 辅助供应商管理审核** | 对报名单位的资质、风险、关联关系进行审核。 | AI | 报名资料 | 审核意见、筛选结果 |
|
||
| **组织评审** | 对报名单位的业绩、纪委审核情况进行综合评审。 | 相关部门人员 | 报名资料+审核意见 | 评审意见 |
|
||
| **形成报名通过单位名单** | 根据评审结果确定通过报名的单位名单。 | 相关部门人员 | 评审意见 | **《报名通过单位名单》** |
|
||
| **接收短名单** | 接收经评审通过的供应商短名单（邀请招标）或报名通过单位名单（公开招标），作为后续招标文件发放的依据。 | 招标人员 | 《供应商短名单》或《报名通过单位名单》 | 已接收的短名单 |
|
||
| **库外供应商入库** | ==通过审核的合格供应商，若在库外，则将信息推送到 SRM 中。== | 系统 | 供应商名单 | 供应商在SRM中的ID |
|
||
|
||
#### 业务规则汇总
|
||
| 规则名称 | 规则内容 | 来源 |
|
||
| :------------ | :-------------------------------- | :---------- |
|
||
| **邀请招标供应商数量** | 短名单中供应商数量应≥3家； | 制度5.9.1.b |
|
||
| **公开招标二次寻源** | 设置接口允许二次寻源 | 制度5.9.1.a |
|
||
| **供应商库内优先** | - | 流程活动050 |
|
||
| **竞争性要求** | 短名单中的供应商应规模、实力相当，地域不宜过度集中，避免串标风险。 | 流程文件关键控制点 |
|
||
| **回避原则** | 评审人员与投标单位有利害关系的应回避。 | 《评委管理规定》4.7 |
|
||
| **公告发布渠道** | 寻源公告应在招标门户发布，同步至行业平台。 | 制度5.9.1.a |
|
||
|
||
#### 异常处理
|
||
| 异常场景 | 处理方式 |
|
||
| :---------------- | :------------------------------------------- |
|
||
| **邀请招标推荐供应商数量不足** | AI自动从合格供方库中补充匹配度高的供应商；若仍不足，系统提示转为公开招标或竞争性谈判。 |
|
||
| **公开招标报名数量不足** | 留二次报名接口。 |
|
||
| **供应商资质审核不通过** | 系统自动通知供应商并说明原因，允许在报名截止前修改重新提交。 |
|
||
| **供应商不在库内** | 自动发起供应商注册/认证流程，认证完成前可先参与投标（需在定标前完成入库）。 |
|
||
| **短名单竞争性不足** | AI预警并建议扩大寻源范围或调整名单，专员确认后可强制提交但需备注理由。 |
|
||
#### AI赋能点
|
||
| 活动/节点 | AI能力 | 功能描述 | 优先级 |
|
||
| :------- | :------ | :-------------------------------------------------------- | :-- |
|
||
| 汇总供应商 | 推荐引擎 | 根据采购品类、预算、地域，从合格供方库和外部企业库自动推荐潜在供应商，附推荐理由（历史合作、资质等级、关联风险）。 | P0 |
|
||
| 形成长/短名单 | 知识图谱 | 自动分析供应商之间的关联关系（投资、任职、共同投标历史），预警可能存在的围串标风险。 | P0 |
|
||
| 长名单评审 | 竞争性分析 | 分析长名单中供应商的地域分布、规模层次，输出竞争性评分，提示“地域过于集中”或“实力差距过大”。 | P1 |
|
||
| 供应商管理审核 | OCR+API | 自动识别营业执照、资质证书关键字段，对接工商/天眼查API验证真伪和经营状态。 | P0 |
|
||
| 形成报名通过名单 | 自动汇总 | 根据评审规则自动汇总通过名单，生成《报名通过单位名单》初稿。 | P0 |
|
||
|
||
#### ==AI 智慧寻源子流程==
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[启动AI自动供应商寻源]
|
||
A --> C[SRM库内供应商]
|
||
A --> D[本平台供应商池]
|
||
A --> E[互联网平台]
|
||
|
||
C --> F[AI智能匹配筛选供应商]
|
||
D --> F
|
||
E --> F
|
||
|
||
F --> G[AI主动发送邀请报名信息<br>（短信、电子邮件等）]
|
||
G --> H[AI将寻源结果反馈]
|
||
|
||
H --> K[供应商管理专员结果确认]
|
||
K --> M([流程结束])
|
||
```
|
||
---
|
||
|
||
### 3.3 阶段三：招标立项流程
|
||
|
||
- **对应流程文件**：`8.4.4.3 招标立项流程`、`8.4.4.1 招标供应商长短名单管理流程`
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A([委托生效]) --> B[招标专员指定/系统分配]
|
||
B --> C1{AI检测是否存在<br>同类型未完成立项的需求}
|
||
|
||
C1 -->|存在| C2[推送合并招标建议<br>至招标专员]
|
||
C1 -->|不存在| E[[8.4.4.1 供应商寻源流程]]
|
||
|
||
C2 --> C3{招标专员确认<br>是否合并招标?}
|
||
C3 -->|是| C4[将当前委托合并至<br>已有招标立项]
|
||
C4 --> C5[AI自动修改/更新<br>原招标方案]
|
||
C5 --> D[招标专员复核<br>修改后的招标方案]
|
||
|
||
C3 -->|否| E
|
||
E --> C[AI 生成招标方案]
|
||
B -->|并行| C
|
||
C --> D
|
||
|
||
D --> N{招标方案评审}
|
||
N -->|驳回| D
|
||
N -->|通过| O{立项审批}
|
||
O -->|通过| P[一键向过审供应商<br>定向发送招标文件]
|
||
O -->|驳回| D
|
||
P --> End([结束])
|
||
|
||
C5 -.->|合并后跳过独立立项| O
|
||
```
|
||
|
||
|
||
**==流程合并待确认==**
|
||
#### 关键表单
|
||
- **《供应商长名单》、《供应商短名单》、《报名通过单位名单》**（来自8.4.4.1流程）
|
||
- **《评标委员会》**（BH-SCM-JL-011）：在立项阶段初步确定工作领导小组。
|
||
|
||
#### 详细说明
|
||
|
||
| 项目 | 内容 |
|
||
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||
| **触发条件** | 招标委托审批通过。 |
|
||
| **输入** | 生效的《招标委托表》、供应商池数据、系统中未完成立项的同类型委托。 |
|
||
| **输出** | 审批通过的《招标方案》、寻源公告、供应商短名单/报名通过名单；或合并后的原立项更新。 |
|
||
| **角色操作** | - **招标专员**：接收合并建议并决策，编制/复核招标方案（含标段划分、评标办法）、组织评审、提交审批。 <br>- **AI**：检测同类型需求、生成合并建议、修改招标方案。 <br>- **审批人**：对所提报招标方案进行审批。路径：二级部门负责人 → 一级部门负责人 → (50万以上)分管公司领导 → (500万以上)总裁。**审批人有招标专员选择，系统仅作推荐和提醒**。 <br>- **相关部门**：评审报名单位业绩。 |
|
||
| **评分方法编辑** | 通过模板选择后进行修改，系统提供维护模板库功能。 |
|
||
| **业务规则** | - 合并招标的判断标准：采购品类相同或高度相似、技术要求可兼容、供货/服务周期重叠、预算来源可合并或独立核算。 <br>- 招标方案评审需包括：技术文件、拟邀请单位、评标办法等。 <br>- 合并后的招标方案仍需经过评审和审批流程。 |
|
||
| **异常处理** | - 合并建议被拒绝：进入正常寻源与招标方案生成流程。 <br>- 合并后原方案修改不通过：退回专员重新复核。 <br>- 合并建议被拒绝后，后面仍能执行合并（只要双方立项流程未结束）<br>- 委托合并之后，后面仍可以重新拆分（只要双方立项流程未结束）<br><br>- 审批驳回：专员修改后重新提交。 <br>- 其它原因退回：因其它原因无法立项可将资料退回到委托方。 |
|
||
| **AI赋能** | - **同类型需求检测**：基于NLP语义分析和采购品类编码，自动检索系统中“委托生效但未完成立项”的同类型需求。 <br>- **合并建议生成**：输出《合并招标建议书》，包含可合并项目列表、预算汇总、时间冲突分析、预期效益估算。 <br>- **招标方案自动修改**：合并后自动调整原方案的标段划分、采购数量、预算总额、供应商名单、时间安排等。 <br>- **主动寻源**：基于采购品类，从潜在供应商池推荐新供应商。 <br>- 自动校验推荐供应商与黑名单、利益冲突。 |
|
||
|
||
---
|
||
|
||
### 3.4 阶段四：供应商投标
|
||
|
||
- **对应流程文件**：`8.4.4.4开标及评标流程`（活动010-030）
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A([公告发布]) --> B[供应商登录]
|
||
B --> C{是否收取标书费}
|
||
C -->|是| D[供应商缴纳标书费]
|
||
C -->|否| E[供应商查看招标文件]
|
||
D -->E
|
||
E --> H[供应商缴纳保证金<br>参考8.4.4.6保证金流程]
|
||
H --> K[供应商上传投标文件]
|
||
K --> M{是否符合开标条件}
|
||
M -->|是|N[[专家抽取与评标准备]]
|
||
M -->|否|P{废标审批}
|
||
P -->|驳回|N
|
||
P -->|通过|Q([废标])
|
||
```
|
||
|
||
#### 关键表单
|
||
- 无新增表单，主要产生《报名通过单位名单》。
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :-------- | :------------------------------------------------------------------------------------------------------ |
|
||
| **触发条件** | 招标文件发送。 |
|
||
| **输入** | 供应商注册信息、资质文件、缴费凭证。 |
|
||
| **输出** | 审核通过的供应商名单、投标文件存证。 |
|
||
| **角色操作** | - **供应商**：注册、报名、缴费、上传标书。<br>- **AI**：自动审核资质、验真、对账。<br>- **相关部门人员**：对报名单位业绩等进行评审。 |
|
||
| **标书费收取** | ==是否收取标书费以及标书费的金额在招标方案制定确定。<br>供应商缴纳标书费后向平台提交转账凭证，平台发起审批向财务确认，确认后才能查看招标文件内容。== |
|
||
| **缴纳保证金** | ==供应商缴纳保证金后，向平台提交保证金转账证据，平台发起审批向财务确认，确认后自动转为保证金缴纳状态。== |
|
||
| **业务规则** | - 投标保证金≤预算2%，最高80万元（仅提醒）（制度5.9.3.1）。<br>- 投标文件必须加密（**==系统加密/个人加密，待确认==**），开标前不可解密。 |
|
||
| **异常处理** | - 缴费未到账：系统轮询支付网关 |
|
||
| **AI赋能** | - **OCR识别**：提取资质证书关键字段。<br>- **真伪核验**：对接工商/税务API验真。<br>- **自动对账**：支付回调后更新缴费状态。<br>- **区块链存证**：存证投标文件哈希。 |
|
||
|
||
---
|
||
|
||
### 3.5 阶段五：专家抽取与评标准备
|
||
|
||
- **对应流程文件**：`8.4.4.4 开标及评标流程`（活动050）
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A([符合开标条件]) --> B[AI根据专业匹配专家库]
|
||
B --> C[招标专员设置抽取规则<br>可灵活设置规则]
|
||
C --> D[系统随机抽取]
|
||
D --> H[确定专家名单]
|
||
H --> I["发送邀请"]
|
||
I --> J{专家确认？}
|
||
J -->|确认| K[签署《评标纪律承诺书》]
|
||
J -->|拒绝| H
|
||
K --> L[评标小组组建完成]
|
||
L --> M["截标(手动)"]
|
||
M-->End([结束])
|
||
```
|
||
|
||
#### 关键表单
|
||
- **《评标纪律承诺书》**（BH-SCM-JL-014）
|
||
- **《招标评委签到表》**（BH-SCM-JL-013）
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :------- | :----------------------------------------------------------------------------------------------------------------------------- |
|
||
| **触发条件** | 招标专员判断符合开标条件。 |
|
||
| **输入** | 项目信息、专家库数据。 |
|
||
| **输出** | 专家名单、承诺书签署记录。 |
|
||
| **角色操作** | - **招标专员**：确认抽取规则。<br>- **AI**：匹配、抽取、校验回避。<br>- **专家**：确认参与、签署承诺书。 |
|
||
| **业务规则** | - 评委人数：最低价法≥3人单数；综合评估法≥5人单数（评委管理规定4.1.3）。<br>- 抽取时间：开标前24小时内（评委管理规定4.5.1）。<br>- 回避原则：投标人近亲属、项目主管部门人员、有经济利益关系者（仅提醒）（评委管理规定4.7）。 |
|
||
| **异常处理** | - 专家人数不足：从外部专家库补充或放宽专业范围。<br>- 专家临时缺席：从备选库重抽。 |
|
||
| **AI赋能** | - **智能匹配**：根据品类和技术复杂度推荐匹配专家。<br>- **知识图谱反欺诈**：自动挖掘专家与供应商的隐性关联，预警利益冲突。 |
|
||
|
||
---
|
||
|
||
### 3.6 阶段六：开标与评标
|
||
|
||
- **对应流程文件**：`8.4.4.4 开标及评标流程`（活动060-120）
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A([到达开标时间]) --> B[一键开标/解密/脱敏]
|
||
B --> C{评标方法判断}
|
||
|
||
C -->|综合评估法| D1[评委在线盲评打分]
|
||
D1 --> D2[AI分析偏离度并提醒复核]
|
||
D2 --> D3[系统汇总得分<br>+AI价格分析/雷同检测]
|
||
D3 --> D4[生成评标汇总表<br>按综合得分排序]
|
||
|
||
C -->|最低价法| E1[检查实质性响应]
|
||
E1 --> E2[有效投标人≥3家?]
|
||
E2 -->|否| E3[转入不足三家处理流程<br>招标制度5.11.3]
|
||
E2 -->|是| E4[按报价从低到高排序]
|
||
E4 --> E5[AI检测异常低价并提请复核]
|
||
E5 --> E6[生成评标汇总表<br>按报价排序推荐中标]
|
||
|
||
D4 --> F[价格谈判和修改]
|
||
E6 --> F
|
||
E3 --> F
|
||
|
||
F-->G[重新生成评标汇总表并排序]
|
||
|
||
G-->End([进入定标阶段])
|
||
```
|
||
|
||
|
||
|
||
定标之前留修改价格接口，修改后再重新排序。
|
||
#### 关键表单
|
||
- **《投标企业签到表》**（现场/电子邮件/SRM开标）（BH-SCM-JL-012）
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :------- | :------------------------------------------------------------------------------------------------------------------------ |
|
||
| **触发条件** | 到达招标文件规定的开标时间。（手动确认） |
|
||
| **输入** | 所有加密投标文件、评标办法。 |
|
||
| **输出** | 评委打分表、雷同检测报告、价格分析报告、得分汇总表。 |
|
||
| **角色操作** | - **系统**：自动开标、解密、脱敏、分发、汇总。<br>- **评委**：在线打分、填写评审意见。<br>- **AI**：偏离度分析、价格分析、雷同检测。<br>- **招标人员**：判断是否符合招标条件。 |
|
||
| **业务规则** | - 有效投标人低于3家，若评委认定仍有竞争性，经评标委员会工作领导小组批准后可继续评标（制度5.11.3）。<br>- 技术标与商务标分开评审。 |
|
||
| **异常处理** | - 不符合招标条件（投标人不足）：经审批后废标。 |
|
||
| **AI赋能** | - **自动脱敏**：NLP识别并隐藏供应商身份信息。<br>- **雷同检测**：文本相似度计算，高亮显示高相似段落。<br>- **价格分析**：基于历史数据标注异常低价/高价。<br>- **业绩发票验真**：OCR+税务局API验真。 |
|
||
|
||
---
|
||
|
||
### 3.7 阶段七：定标与审批
|
||
|
||
- **对应流程文件**：`8.4.4.5 定标流程`
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A[评标结束] --> B0[AI 生成评标报告]
|
||
B0-->B[招标专员修改确认评标报告<br>活动010]
|
||
B --> C[AI给出中标建议]
|
||
C --> D[招标专员审核修改]
|
||
D -->F[发起定标审批<br>活动020]
|
||
F --> H{执行定标审批<br>活动030}
|
||
H -->|通过| I[定标生效]
|
||
H -->|驳回| J[退回复议]
|
||
J --> K[评标小组重评]
|
||
K --> B
|
||
I --> L["发布中标结果(AI)<br>活动040"]
|
||
L --> M["发送通知给所有投标方<br>(AI生成草稿，经招标管理部总经理电子签名后自动发送)"]
|
||
|
||
subgraph SRM[SRM平台]
|
||
N[招标资料转交至委托部门]
|
||
N --> N2[[合同生成]]
|
||
end
|
||
M -->|转交|SRM
|
||
N2 --> P["退还投标保证金<br>(一键向财务发起审批)"]
|
||
P --> Q[审核]
|
||
Q --> R[[招标资料归档]]
|
||
R-->End([结束])
|
||
```
|
||
|
||
|
||
#### 关键表单
|
||
- **《评标报告》**
|
||
- **《中标后资料交接单》**（BH-SCM-JL-020）
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :-------- | :----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||
| **触发条件** | 评标汇总完成。 |
|
||
| **输入** | 评标汇总表、AI分析报告。 |
|
||
| **输出** | 评标报告、中标公示、中标通知书。 |
|
||
| **角色操作** | - **招标专员（活动010,020）**：编制报告、发起审批。<br>- **审批人（活动030）**：执行定标审批，路径见审批矩阵。<br>- **系统（活动040-060）**：发布结果、转交资料、归档。 |
|
||
| **保证金退还** | 支持按招标项目、招标专员分类批量勾选供应商合并退费。向 OA 发送退费审批。 |
|
||
| **业务规则** | - 原则上按综合排名第一推荐中标（制度5.11.4）。<br>- 定标审批权限（流程文件审批矩阵）：50万元以下二级部门负责人→一级部门负责人；500万元以下→分管公司领导；以上→总裁。**审批人由招标专员选择，系统仅作推荐和提醒。**<br>- 中标资料须转交委托部门（制度5.12）。 |
|
||
| **异常处理** | - 审批驳回：退回评标小组复议。<br>- 中标供应商放弃：按排名顺延，重新报批。 |
|
||
| **AI赋能** | - **AIGC评标报告**：自动生成结构化报告。<br>- **中标建议可解释性**：提供各方案优劣势对比。 |
|
||
|
||
---
|
||
|
||
### 3.9 阶段九：资料归档与全程监督
|
||
|
||
#### 流程图
|
||
```mermaid
|
||
graph TD
|
||
A[合同签订完成] --> B[系统自动收集全流程资料]
|
||
B --> C[按制度5.16清单整理]
|
||
C --> D[生成电子归档文件包]
|
||
D --> E[推送至电子档案系统]
|
||
E --> F[归档完成]
|
||
F --> G[审计人员随时查阅]
|
||
G --> H[BI看板实时展示]
|
||
```
|
||
|
||
#### 关键表单
|
||
- 归档清单见制度5.16，包括：《招标委托资料》、《招标文件》、《投标单位签到表》、《评委签到表》、《评标纪律承诺书》、《投标文件》、《评标报告》、《中标通知书》等。
|
||
|
||
#### 详细说明
|
||
| 项目 | 内容 |
|
||
| :------- | :------------------------------------------------------------------------------------------------ |
|
||
| **触发条件** | 合同签订完成。 |
|
||
| **输入** | 全流程文档。 |
|
||
| **输出** | 归档文件包、审计日志。 |
|
||
| **角色操作** | - **系统**：自动收集、整理、推送。<br>- **审计/合规**：查询、导出。 |
|
||
| **业务规则** | - 归档资料必须包括制度5.16列明的所有文件。 |
|
||
| **归档系统** | 紫光档案管理系统 |
|
||
| **异常处理** | - 资料缺失：系统提示缺失项，要求补传。 |
|
||
| **AI赋能** | - **智能分类**：自动分类并按规范命名。<br>- **缺失检测**：对比归档清单，自动识别缺失文件。<br>- **审计辅助**：支持自然语言查询（如“查询2025年所有围标疑似项目”）。 |
|
||
|
||
---
|
||
|
||
### 3.10 关键业务规则汇总
|
||
|
||
| 规则名称 | 具体内容 | 来源 |
|
||
| :----------- | :----------------------------------------------------------------- | :-------------------- |
|
||
| **招标门槛** | 工程/货物≥50万；服务≥30万 | 《招标管理制度》5.1 |
|
||
| **评委人数** | 最低价法≥3人单数；综合评估法≥5人单数 | 《评委管理规定》4.1.3 |
|
||
| **评委抽取时间** | 开标前24小时内 | 《评委管理规定》4.5.1 |
|
||
| **回避情形** | 投标人近亲属、项目主管部门、经济利益关系 (仅作提醒) | 《评委管理规定》4.7 |
|
||
| **保证金上限** | 不超过预算2%，最高80万元（仅作提醒） | 《招标管理制度》5.9.3.1 |
|
||
| **邀请招标供应商数** | ≥3家 | 《招标管理制度》5.9.1 |
|
||
| **废标条件** | 有效投标人＜3且无竞争性；所有投标不符合要求 | 《招标管理制度》5.11.2/5.11.3 |
|
||
| **审批权限** | 50万/500万为分界，对应二级部门负责人/一级部门负责人/分管领导/总裁。（**最终审批人由招标专员选择，系统仅作推荐和提醒**） | 各流程文件审批矩阵 |
|
||
| **内部专家奖励** | 最低价法50元/人；综合评估法100元/人 | 《评委管理规定》4.9 |
|
||
| **外部专家报酬** | 3小时内500元，超时每增1小时+100元，日上限1500元 | 附录B |
|
||
|
||
---
|
||
|
||
## 第四章 数据安全机制
|
||
|
||
### 1. 总体安全策略与目标
|
||
|
||
为确保招标全流程数据的机密性、完整性和可用性，针对内外部威胁（包括具备服务器操作权限的开发人员、DBA、运维人员），建立 **“数据全程加密、密钥动态漂移、权限最小化、AI按需脱敏”** 的纵深防御体系。所有加密与密钥管理均在应用层和内存中实现。
|
||
|
||
**核心目标**：
|
||
- **防窥探**：即使攻击者获得服务器操作权限，也无法直接读取数据库中的招标敏感数据（如投标报价、专家打分、关联关系图谱）。
|
||
- **防泄露**：静态文件加密存储，传输全程加密，密钥在内存中动态漂移，杜绝落盘。
|
||
- **防越权**：前后端双重权限校验，AI Agent仅能通过流程状态门控获取被授权数据，禁止通过对话方式旁路获取受限信息。
|
||
- **可审计**：所有数据访问、密钥迁移、AI调用行为均记录不可篡改日志（使用哈希链+数字签名代替区块链）。
|
||
|
||
### 2. 密钥管理机制：内存动态漂移 + 应用层分割
|
||
|
||
#### 2.1 设计原则
|
||
- **密钥永不落盘**：加密密钥仅在服务器内存中生成和存储，禁止写入任何持久化存储（磁盘、SSD、数据库）。
|
||
- **动态漂移**：密钥的存储内存地址每隔若干小时随机迁移，同时变更密钥本身（旧密文使用旧密钥解密后使用新密钥重加密），降低内存被暴力扫描窃取的风险。
|
||
- **密钥分割**：单条数据密钥被分割为2~3个分片，保存在不同进程/容器的内存区域，使用时分片聚合，用完即时销毁。
|
||
|
||
### 3. 静态数据加密
|
||
|
||
#### 3.1 数据库加密
|
||
| 加密粒度 | 实施方案 |
|
||
| :--- | :--- |
|
||
| **透明加密** | 使用磁盘加密作为基础防护，防止物理磁盘被盗。但透明加密不防止 DBA 直接读取数据库文件，因此仍需字段级加密。 |
|
||
| **字段级加密** | 对极端敏感字段采用应用层字段加密：每个字段使用独立 DEK，DEK 密文存储在同一行的单独列中。 |
|
||
| **索引混淆** | 加密字段不能直接用于条件查询，采用确定性加密生成可搜索的盲索引，盐值也存在于内存中，定期轮换并重建索引。 |
|
||
|
||
#### 3.2 静态文件加密
|
||
所有上传文件（投标书PDF、资质扫描件、专家承诺书、音视频记录）采用信封加密：
|
||
1. 每个文件随机生成文件密钥，内存中保存。
|
||
2. 使用 FEK 对文件进行加密，分块上传（每块 4MB），每块独立加密。
|
||
3. FEK 使用主密钥加密后，作为文件元数据的一部分存储于对象存储的字段或单独数据库表。
|
||
4. 文件在对象存储中始终处于密文状态，即使直接拷贝也无法读取。
|
||
|
||
#### 3.3 备份与快照加密
|
||
- 数据库备份、对象存储快照必须使用独立的备份密码。
|
||
- 备份密钥由双人控制（分段存储于两个保险柜），恢复时需要两人输入各自的密码段。
|
||
|
||
### 4. 传输加密与 API 安全
|
||
|
||
#### 4.1 全链路加密
|
||
- 所有对外服务（前端、API、Webhook）强制启用加密算法，禁用弱密码套件。
|
||
- 使用内部 CA 签发服务端证书，客户端验证服务端证书指纹。
|
||
- 服务间调用（微服务、AI Agent）采用双向认证。
|
||
|
||
### 5. 前后端权限隔离与角色端口设计
|
||
|
||
#### 5.1 角色与端口映射
|
||
平台为不同角色分配独立的访问端口（或子域名），并在网关层绑定最小权限策略。
|
||
|
||
#### 5.2 前后端双重权限校验
|
||
- **前端**：登录后获取 JWT，JWT 中仅包含角色和用户 ID，不包含任何权限矩阵。前端根据角色代码展示不同菜单，但关键按钮（如“查看报价”）仍需要后端二次确认。
|
||
- **后端**：每个 API 调用都会执行 **Policy Enforcement Point (PEP)**，根据用户 ID + 资源 ID 查询：
|
||
- 用户是否属于该项目的相关角色（如：该专家是否被分配到该项目评委组）
|
||
- 当前流程状态是否允许访问该资源（例如：开标前任何人不能查看报价文件）
|
||
|
||
### 6. AI Agent 安全隔离与按需数据访问
|
||
|
||
#### 6.1 基于角色 AI Agent 架构
|
||
每个角色（供应商、专家、招标专员、审批人、管理员）分别部署一个独立的 AI Agent 容器，使用不同的 API Key 和身份凭证。Agent 之间的内存和密钥完全隔离。
|
||
|
||
```mermaid
|
||
graph TB
|
||
subgraph 用户层
|
||
U1[供应商]
|
||
U2[评标专家]
|
||
U3[招标专员]
|
||
U4[审批领导]
|
||
U5[管理员]
|
||
U6[其他角色 ...]
|
||
end
|
||
|
||
subgraph AI助手层
|
||
A1[供应商助手]
|
||
A2[专家助手]
|
||
A3[招标助手]
|
||
A4[审批助手]
|
||
A5[管理助手]
|
||
A6[其他助手 ...]
|
||
end
|
||
|
||
subgraph 安全管控层
|
||
CHECK[对话安全守卫]
|
||
GATE[数据访问门禁]
|
||
end
|
||
|
||
subgraph 数据与知识层
|
||
KB[公开知识库<br>操作手册/流程教学]
|
||
BIZ[业务数据<br>报价/评分/投标文件]
|
||
end
|
||
|
||
subgraph 输出层
|
||
OUT[安全答复]
|
||
end
|
||
|
||
U1 --> A1
|
||
U2 --> A2
|
||
U3 --> A3
|
||
U4 --> A4
|
||
U5 --> A5
|
||
U6 --> A6
|
||
|
||
A1 --> CHECK
|
||
A2 --> CHECK
|
||
A3 --> CHECK
|
||
A4 --> CHECK
|
||
A5 --> CHECK
|
||
A6 --> CHECK
|
||
|
||
CHECK -->|安全且需数据| GATE
|
||
CHECK -->|教学或越权| KB
|
||
|
||
GATE -->|权限+流程通过| BIZ
|
||
BIZ --> OUT
|
||
KB --> OUT
|
||
```
|
||
|
||
#### 6.2 流程驱动的数据门控
|
||
Agent 在调用任何业务数据前，必须通过统一数据网关验证请求合法性。网关检查：
|
||
1. **角色匹配**：Agent 的 JWT 中角色声明是否与目标数据要求一致。
|
||
2. **流程状态**：查询招标项目的工作流引擎当前状态，根据前述“状态门控”决定是否放行。
|
||
3. **数据脱敏**：即使允许访问，返回的数据也会根据角色自动脱敏。
|
||
|
||
#### 6.3 AI 对话隔离：防止越狱查询
|
||
当流程状态为“数据不可见”时，AI Agent 进入教学/流程提醒模式：
|
||
- Agent 的上下文强制注入：`当前阶段禁止透露任何项目数据，包括报价、投标人名称、评分。若用户询问数据，统一回答：“暂未到查看时间，请等待系统通知。如需帮助，请描述您的问题（如：如何上传文件？）”。`
|
||
- 后端增加对话内容审计：每次用户询问，AI Agent 先将问题发送至越狱检测服务（基于语义相似度和正则），命中敏感词（“报价”、“分数”、“谁中标了”）且当前流程禁止时，直接拦截并记录异常日志。
|
||
- 对于普通操作教学（“如何修改密码”），使用独立的“小滨-助手”知识库（不含任何项目数据），不涉及数据查询。
|
||
|
||
#### 6.4 Agent 调用审计
|
||
- 记录每个 Agent 发起的每一次数据请求（包括时间、项目ID、请求参数、返回数据指纹）。
|
||
- 审计日志写入哈希链日志表，防止管理员篡改。
|
||
|
||
### 7. 无死角防窥探
|
||
|
||
即使开发人员、拥有服务器 root 权限或数据库管理员权限，也无法直接读取到明文敏感数据，真正做到无死角防窥探。
|
||
|
||
#### 7.1 开发与调试环境
|
||
- **脱敏数据镜像**：开发测试环境使用完全脱敏的伪造数据（通过数据脱敏工具生成），不包含真实供应商、报价。
|
||
- **密钥沙盒**：开发环境使用独立的种子口令，无法接触生产密钥。
|
||
- **CI/CD 隔离**：构建流水线中使用的变量（如数据库密码）来自 Vault 动态 secret，构建完成后立即失效。
|
||
|
||
### 8. 审计与监控
|
||
|
||
#### 8.1 审计日志保护（哈希链 + 数字签名）
|
||
采用 **哈希链 + 数字签名** 保证日志不可篡改：
|
||
- 每条审计日志记录包含：`id`、`时间`、`操作者`、`操作内容`、`数据指纹`。
|
||
- 每条日志的哈希字段指向前一条日志的哈希。
|
||
- 每小时，系统对当前哈希链的最新哈希值，使用审计专用私钥进行签名，并将签名值保存到外部（如另一个数据库表或文件）。
|
||
- 验证时，重新计算哈希链，比对签名。
|
||
|
||
#### 8.2 审计内容范围
|
||
| 审计对象 | 采集内容 | 保留期限 | 存储方式 |
|
||
| :--- | :--- | :--- | :--- |
|
||
| 用户访问日志 | 谁、何时、从哪个 IP、访问了哪个 API、返回了哪类数据（脱敏后指纹） | 7 年 | 哈希链日志表 + 离线归档 |
|
||
| 密钥操作日志 | 密钥生成时间、漂移时间、销毁时间、涉及的内存地址范围（经过哈希） | 3 年 | 加密存储，仅合规人员可读 |
|
||
| AI Agent 调用日志 | Agent 角色、请求参数、是否被拦截、越狱检测结果 | 3 年 | 同上 |
|
||
| 数据库 DDL/DML | 所有 `INSERT/UPDATE/SELECT` 敏感表记录 | 永久 | 同步至独立 SIEM |
|
||
| 异常告警 | 单用户异常访问、密钥漂移失败次数 | 实时推送 | 飞书/短信通知安全运维 |
|
||
| 过程文件 | 存放于服务器，数据库中记录URL | 15 年 | 加密 |
|
||
|
||
### 9. 存证功能
|
||
|
||
#### 9.1 存证目标与原则
|
||
- **独立存证表**：存证记录独立于业务数据库，使用哈希链防止篡改。
|
||
- **可信时间戳**：对关键存证事件，调用第三方可信时间戳服务赋予法律效力。
|
||
- **与加密机制协同**：存证哈希基于解密后的明文（但只传哈希，不传明文）。
|
||
|
||
#### 9.2 存证范围与触发事件
|
||
| 阶段 | 存证事件 | 存证内容（哈希对象） | 触发时机 |
|
||
| :--- | :--- | :--- | :--- |
|
||
| **委托** | 招标委托单提交审批 | 委托单全文 | 用户点击“发起审批” |
|
||
| | 委托审批通过 | 审批记录+签字意见 | OA回调“审批完成” |
|
||
| **立项** | 招标方案确认 | 招标方案PDF | 立项审批通过 |
|
||
| | 供应商短名单确认 | 短名单（供应商ID+推荐理由） | 短名单审批完成 |
|
||
| **文件编制** | 招标文件定稿 | 招标文件PDF | 文件加密发布前 |
|
||
| | 澄清/修改公告 | 澄清文件PDF | 发布前 |
|
||
| **投标** | 投标文件上传完成 | 投标文件哈希+上传时间戳 | 供应商上传加密文件成功后 |
|
||
| | 保证金缴纳凭证 | 银行回单PDF | 支付网关回调成功 |
|
||
| **开标** | 开标记录 | 开标现场音视频文件哈希+关键截屏 | 开标结束时 |
|
||
| **评标** | 评委打分 | 每个评委的评分表（含打分项） | 评委提交评分 |
|
||
| | 偏离度复核记录 | AI提醒+评委确认意见 | 评委复核确认 |
|
||
| **定标** | 评标报告 | 评标报告PDF | 报告定稿 |
|
||
| | 中标结果审批 | 定标审批单+领导签字 | 定标审批通过 |
|
||
| **合同** | 合同签订 | 电子合同PDF | 双方电子签章完成 |
|
||
| **归档** | 全项目归档包 | 所有存证哈希组成的Merkle树根 | 归档完成时 |
|
||
|
||
#### 9.3 验证与司法出证
|
||
- **内部验证**：在平台“存证验证”页面输入项目号，系统重新计算当前数据哈希，与存证哈希比对，显示“通过”或“篡改”。
|
||
- **司法出证**：管理员导出指定项目的完整存证包（含所有事件的哈希链、签名、时间戳证书），提交法院。法院可通过第三方时间戳官网核验。
|
||
|
||
### 10. 应急响应与备份
|
||
|
||
#### 10.1 数据备份
|
||
- 全量备份（加密）每天一次，保留30天。
|
||
- 增量备份每6小时一次。
|
||
|
||
#### 10.2 入侵响应
|
||
检测到内存扫描、暴力破解、异常数据导出行为 → 自动触发 **应急模式**：
|
||
- 冻结当前所有用户会话
|
||
- 强制销毁所有内存中的 DEK（触发全部数据锁定）
|
||
- 通知安全团队介入
|
||
|
||
### 11. 合规性说明
|
||
|
||
以上设计满足以下法规与标准：
|
||
- **《网络安全法》**：数据加密、日志留存6个月以上。
|
||
- **《个人信息保护法》**：供应商联系人手机号、身份证等敏感个人信息采用字段级加密，展示时脱敏。
|
||
- **等保2.0三级**：符合数据完整性、保密性、备份恢复、安全审计要求（等保不强制要求HSM，只要密钥管理得当即可）。
|
||
- **ISO 27001**：密钥管理、访问控制、事件响应覆盖。
|
||
- **《招标投标法实施条例》（国务院令第613号）**（第五十六条：“招标人或者其委托的招标代理机构应当妥善保管招标过程中的文件资料，存档备查，并至少保存十五年。”）15年 + 诉讼时效。
|
||
|
||
---
|
||
|
||
# 第五章 供应商无感登陆需求
|
||
|
||
## 5.1 需求背景
|
||
|
||
滨化集团已建有 **SRM 供应商关系管理平台**，用于供应商注册、认证、合同执行、绩效评估等业务。新建的 **STP 智慧招标平台** 负责招标全流程管理，两个平台面向共同的供应商群体，存在大量业务交叉与流转（如寻源阶段从 SRM 读取供应商库、定标后资料转交 SRM 生成合同）。
|
||
|
||
目前供应商在两个平台拥有独立的账号体系，需分别注册、记忆不同的用户名/密码，在跨平台操作时需重复登录，严重影响用户体验与业务效率。为实现 **“一次登录，两平台通行”** 的无缝体验，特提出供应商无感登陆需求。
|
||
|
||
## 5.2 核心场景
|
||
|
||
| 场景编号 | 场景描述 | 触发条件 | 期望行为 |
|
||
| :----- | :---------------- | :---------------------------------------------- | :------------------------------------------------------------------ |
|
||
| **S1** | SRM 存量供应商首次访问 STP | 供应商已在 SRM 注册并激活账号，点击 STP 招标公告链接或直接访问 STP 门户 | 使用 SRM 用户名/密码即可登录 STP，无需额外注册；STP 自动同步其 SRM 基础信息（企业名称、统一社会信用代码、联系人等） |
|
||
| **S2** | STP 注册供应商首次访问 SRM | 供应商已在 STP 注册并参与投标，因业务需要进入 SRM 查看合同或执行订单 | 使用 STP 用户名/密码即可登录 SRM，无需重复注册；SRM 自动创建或关联其供应商档案 |
|
||
| **S3** | 已在任一平台登录，跳转至另一平台 | 供应商当前在 STP 处理投标事务，点击页面内嵌的 SRM 链接（如“查看合同模板”）；或反之 | 无需重新输入凭证，直接无感跳转至目标平台，保持登录态 |
|
||
|
||
## 5.3 安全要求
|
||
|
||
无感登陆必须在保证便捷性的同时，满足集团数据安全政策及以下额外要求：
|
||
|
||
| 安全项 | 要求 |
|
||
| :------------- | :---------------------------------------------------------------------------------------------------------------------- |
|
||
| **令牌安全** | JWT（ID Token）有效期 **≤ 30 分钟**，Refresh Token 有效期 **≤ 7 天**，且 Refresh Token 仅存储在 Vendor SSO 服务端，不暴露给前端。 |
|
||
| **跨平台跳转票据安全** | 跳转票据（ticket）使用 **RS256** 非对称签名（STP 私钥签名，SRM 公钥验证；反之亦然），票据有效期 ≤ 5 分钟，防止重放攻击。 |
|
||
| **传输加密** | 所有 交互必须使用 **HTTPS + TLS 1.3**，禁用弱加密套件。 |
|
||
| **最小权限原则** | 供应商在 STP 仅能访问与其投标项目相关的数据；在 SRM 仅能访问与其合同/订单相关的数据。Vendor SSO 签发的 ID Token 中仅包含用户标识和基础声明，具体业务权限由各平台依据本地业务规则二次校验（见第四章 5.2）。 |
|
||
| **多因素认证（MFA）** | 涉及修改密码、更换手机号、绑定新邮箱等敏感操作时，强制短信验证码二次认证。登录时可配置是否启用 MFA（初期暂不强制）。 |
|
||
| **异常监控与锁定** | 记录所有登录尝试（IP、设备指纹、时间），异常行为（短时间内多地登录、频繁失败）触发告警并临时锁定账号（锁定 30 分钟）。 |
|
||
| **审计日志** | 所有认证请求、令牌发放、跳转票据生成与验证、用户信息同步等操作均记录审计日志，保留期限 ≥ 3 年。 |
|
||
|
||
---
|
||
|
||
## 第六章 待确定事项汇总
|
||
|
||
* **委托自动合并功能**（同类型多立项合并）暂缓落地，根据业务使用频次确定是否开发。
|
||
* **投标文件加密方案**
|
||
两种方案待定：
|
||
①供应商自主设密钥，开标现场输密码解密（弊端：联系人失联无法开标）；
|
||
②系统统一加密、平台自动解密（弊端供应商不信任数据安全）。
|
||
经商定，以方案②，系统统一加密的方式进行。
|
||
* **标书费配置**
|
||
1. 收费节点定于标书发放前，付费后解锁招标文件查看权限；
|
||
2. 招标方案制定时可选择是否收取标书费；
|