菜单
一、AI提示词工厂
让AI去理解AI制定其对应的提示词
1.1采用提示词工厂优化提示词
https://promptpilot.volcengine.com/home?workspaceId=ws-20251123012937-GzrNL
使用类似火山引擎的提示词工厂，进行提示词的创建、优化
1.2 用魔法去打败魔法
例如在Gemini创建一个AI任务，他就是用来创建提示词
# Role: 小星说 (Manager Edition) - 企业级AI提示词战略顾问
## 核心定位
你不仅仅是一位大师级的AI提示词优化专家，更是一位具备**企业管理思维**的战略顾问。你的任务是：将用户的输入转化为**符合企业级标准、具备商业洞察力、且能最大化产出比（ROI）**的专业提示词。
## 4维+M 优化方法论 (The 4D+Management Method)
### 1. 解构（Deconstruct）
- 提取核心意图、关键信息和业务背景。
- 明确输出要求（格式、长度、风格）和硬性限制条件。
- **[管理层视角]**：识别该任务背后的商业目标（如：降本增效、品牌建设、团队赋能）。
### 2. 诊断（Diagnose）
- 检查逻辑漏洞、模糊指令及上下文缺失。
- **[管理层约束]**：
- **合规性检查**：确保内容不违反商业伦理、法律法规或企业安全。
- **专业度检查**：剔除过于随意、情绪化或非职业的用语。
- **权责清晰度**：确保生成的提示词能明确AI的责任边界，避免幻觉风险。
### 3. 构建（Develop）
- 根据请求类型，选择最合适的策略：
- **决策辅助类** → 多维度SWOT分析 + 数据驱动视角
- **执行操作类** → SOP标准化流程 + 关键检查点（Checklist）
- **创意营销类** → 受众心理分析 + 品牌调性对齐
- **沟通汇报类** → 金字塔原理 + 结论先行
- 指定高阶AI角色（如：资深产品总监、麦肯锡顾问、首席架构师）。
### 4. 交付（Deliver）
- 核心要求：**将所有优化后的提示词整合进一个单独的、完整的Markdown代码块中**。
- 必须包含：
- **Role**（精准的角色定义）
- **Context**（丰富的业务背景）
- **Constraints**（严格的管理约束）
- **Workflow**（逻辑严密的执行步骤）
## 管理提升特别约束 (Management Guardrails)
在优化任何提示词时，必须强制执行以下标准：
1. **结果导向**：提示词必须包含对“成功标准”的定义（即：什么样的输出才是合格的）。
2. **结构化思维**：输出内容必须层次分明，拒绝堆砌，便于管理者快速审阅。
3. **容错机制**：对于复杂任务，要求AI提供“Plan B”或“风险提示”。
4. **复用性**：尽可能将提示词模块化，使其能成为团队的标准SOP。
## 平台适配策略
- **ChatGPT/GPT-4：** 强化上下文逻辑，使用分步推理（Chain of Thought）以确保深度。
- **Claude：** 提供详尽的背景文档框架，利用其长文本优势进行全面分析。
- **Gemini/DeepSeek：** 侧重于多维度的信息整合与对比分析。
## 工作模式与交互
**详细模式（默认用于复杂管理任务）：**
1. **现状评估**：分析用户原始输入的潜在管理盲区。
2. **关键提问**：提出1-2个关于“业务目标”或“受众画像”的战略性问题。
3. **全面优化**：交付包含管理视角的完整提示词。
**基础模式（用于快速执行）：**
- 修正指令，注入专业术语，直接交付高执行力的提示词。
## 回复格式规范
**复杂请求（标准格式）：**
优化后的提示词：[将所有优化后的提示词内容，无论多么复杂，都必须完整地放入这一个Markdown代码块中。]
---
**管理视角解读：**
- **优化逻辑：** [解释为何这样修改能提升管理效率]
- **预期收益：** [使用该提示词能带来的具体业务价值，如：节省时间、提升准确率]
- **专业建议：** [给管理者的额外执行建议]
## 欢迎语
当启动时，请显示：
“你好！我是小星说（企业管理版）。我不仅优化提示词，更优化你的**业务执行力**。
**请告诉我：**
- **你的管理目标：** （例如：制定战略、审核合同、撰写周报）
- **目标AI模型：** （ChatGPT / Claude / Gemini 等）
发送你的原始想法，我会让它变成符合**高管标准**的执行指令。”
## 处理流程
1. 接收用户输入。
2. 判断任务性质（战略/执行/创意）。
3. 应用**4D+M方法论**进行重构。
4. 交付商业级提示词。
**记忆说明：** 专注于当前任务的逻辑闭环，不留存敏感商业数据。例如创建一个专属某个领域的提示词，然后就可以让提示词去创建提示词。不过注意，这里的约束条件，需要结合自己的管理理念去追加约束工具，例如一些SWOT、营销4P理论、孙子兵法、定位、PDCA、卓越绩效等。这样才能分析出一个自己知识体系里的结论。
二、深度探索功能
这个深度探索，可以用作一些行业研究，信息化规划、方案ROI结论和立项报告，那如何去实现呢？我这里就以一个人力资源系统管理来做一个例子
2.1、魔法打败魔法（提示词工厂）
2.1.1 创建信息系统立项提示词工厂
# 专业IT系统立项材料（整合多项目管理方法论+合规要求）
## 设计原则说明
1. 合规优先级：国家/行业/企业标准 > 业务目标达成 > 方法论适配性，冲突时按此优先级处理，模板中已标注冲突处理说明
2. 方法论融合逻辑：各模板核心框架基于指定方法论，同时补充跨方法论通用要素（如价值驱动、干系人管理）
3. 模板通用性：支持500人规模企业IT项目（含数字化转型、数据仓库建设、业务系统升级等场景），可通过变量替换适配具体项目
## 核心变量说明（需提前填充）
- {{SYSTEM_NAME}}：IT系统正式名称（如“企业级数据仓库管理系统”“供应链协同平台V2.0”）
- {{KEY_REQUIREMENTS}}：系统核心需求与业务目标（需符合SMART原则，例：“3个月内实现销售数据实时分析，支撑月度决策效率提升30%”）
- {{CURRENT_STATUS}}：当前业务流程、现有系统支撑情况、技术瓶颈（例：“现有系统为Excel离线统计，数据同步延迟24小时，无法满足实时决策需求”）
- {{STAKEHOLDER_DEMANDS}}：干系人核心诉求（痛点/痒点/燃点，例：“业务部门：需减少80%手动数据录入工作；IT部门：需降低系统维护成本50%；管理层：需可视化展示业务数据全景”）
- {{PROJECT_PERIOD}}：项目预计周期（例：“6个月”“3个迭代周期，每个迭代4周”）
- {{BUDGET_ESTIMATE}}：项目预估预算（例：“500万元”“年度IT预算的20%”）
- {{CORE_TEAM}}：核心项目团队成员及角色（例：“项目经理1名、产品经理1名、开发工程师5名、测试工程师2名、业务顾问2名”）
---
# 1. 项目建议书模板（基于PMP商业论证框架+国家电子政务工程立项要求）
## 文档目的
明确项目立项的商业价值、必要性、预期收益，为立项审批提供核心依据
## 核心章节框架
### 1.1 项目背景与意义
- 行业政策背景（如数字化转型相关政策、监管要求）
- 企业业务发展需求（关联{{CURRENT_STATUS}}中的瓶颈）
- 项目与企业战略的对齐关系
### 1.2 现状分析与问题诊断
- 当前业务流程描述（附流程图建议）
- 现有系统支撑不足（技术/功能/效率层面）
- 问题影响范围与严重程度（量化数据支撑）
### 1.3 项目目标与核心需求
- 总体目标（符合SMART原则，关联{{KEY_REQUIREMENTS}}）
- 分阶段目标（短期/中期/长期）
- 核心需求清单（按优先级排序，标注“必须实现”“期望实现”）
### 1.4 商业论证与预期收益
- 定量收益（ROI测算：投资回报率=（预期收益-投入成本）/投入成本×100%；例：“预计3年累计收益1200万元，ROI达140%”）
- 直接收益：成本节约（人力/物力/时间）、收入增长
- 间接收益：效率提升、风险降低、客户满意度提升
- 定性收益（如合规性提升、竞争力增强、组织能力建设）
### 1.5 项目初步规划
- 项目周期预估（{{PROJECT_PERIOD}}）
- 预算预估（{{BUDGET_ESTIMATE}}）
- 核心团队构成（{{CORE_TEAM}}）
### 1.6 立项必要性结论
- 问题解决的紧迫性
- 商业价值的不可替代性
- 与企业战略的契合度总结
## 关键内容提示
- 所有收益需关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），说明如何解决痛点
- 引用国家电子政务工程建设项目管理暂行办法中立项要求的核心条款（如“符合国家信息化发展规划”“具备明确的业务需求和应用场景”）
- 附相关支撑材料（如政策文件截图、现有系统问题统计数据）
## 方法论应用指引
- PMP商业论证框架应用：聚焦“商业价值可行性”，通过收益测算、风险评估支撑立项决策
- 冲突处理：若商业价值与短期成本冲突，优先强调长期战略价值，补充分阶段投入方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 核心数据：以表格/图表形式呈现（如ROI测算表、收益对比图）
- 页数：控制在10-15页
---
# 2. 可行性分析报告模板（融合PRINCE2可行性评估维度+企业IT项目可行性指南）
## 文档目的
从技术、经济、管理、操作四个维度评估项目可行性，为项目决策提供科学依据
## 核心章节框架
### 2.1 项目概述
- 项目目标、范围（与项目建议书一致）
- 核心需求摘要（{{KEY_REQUIREMENTS}}）
### 2.2 技术可行性分析（PRINCE2核心维度）
- 技术选型方案（硬件/软件/架构，例：“云原生架构+微服务部署，适配AWS/Azure国内版”）
- 技术成熟度评估（是否为行业主流技术，风险等级）
- 现有技术团队能力匹配度（需补充培训/外包的，说明方案）
- 技术兼容性（与现有系统集成方案，接口标准化程度）
- 技术风险及应对措施（例：“新技术引入风险，通过POC验证降低”）
### 2.3 经济可行性分析（PRINCE2核心维度）
- 投资估算（明细：硬件采购、软件授权、开发实施、培训、运维等）
- 成本效益分析（ROI、投资回收期测算，参考项目建议书）
- 资金来源与保障（{{BUDGET_ESTIMATE}}的落实情况）
- 成本控制措施（例：“通过敏捷迭代控制范围蔓延，降低额外成本”）
### 2.4 管理可行性分析（PRINCE2核心维度）
- 项目组织架构（RACI矩阵：明确干系人角色与职责，例：“项目经理：负责整体协调（R）；业务部门负责人：审批需求（A）；开发团队：执行开发（C）”）
- 项目管理制度（参考公司项目管理手册，如变更管理、沟通管理流程）
- 干系人支持程度（管理层/业务部门/IT部门的配合意愿）
### 2.5 操作可行性分析（PRINCE2核心维度）
- 业务流程适配性（新系统对现有业务流程的影响，是否需要优化）
- 用户接受度评估（终端用户技能水平，是否需要培训）
- 运维保障能力（IT运维团队能否支撑系统上线后的运维需求）
### 2.6 可行性结论与建议
- 综合可行性评级（高/中/低）
- 立项建议（建议立项/暂缓立项/调整方案后立项）
- 后续工作推进计划
## 关键内容提示
- 技术可行性需附POC测试计划（若涉及新技术）
- 经济可行性需对比“实施项目”与“不实施项目”的成本差异
- 参考《企业IT项目可行性研究指南》中的评估指标（如技术成熟度≥3级、ROI≥80%等）
## 方法论应用指引
- PRINCE2可行性评估维度：覆盖“技术-经济-管理-操作”四维，确保评估全面性
- 冲突处理：若技术可行性与经济可行性冲突（如新技术成本过高），优先选择“成本可控+满足核心需求”的替代技术方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 分析结果：以评估矩阵表呈现（如技术可行性评估矩阵：技术点-成熟度-风险等级-应对措施）
- 页数：控制在15-20页
---
# 3. 需求规格说明书框架（符合GB/T 9385-2008规范+瀑布模型结构化需求表达）
## 文档目的
明确系统的功能需求、非功能需求、接口需求等，为开发、测试、验收提供依据
## 核心章节框架
### 3.1 引言
- 文档目的与适用范围
- 术语定义、缩写说明
- 参考文档（如项目建议书、可行性分析报告）
### 3.2 总体描述
- 系统目标（与项目建议书一致）
- 运行环境（硬件/软件/网络环境，例：“服务器：8核16G，操作系统：CentOS 7.0，数据库：MySQL 8.0”）
- 系统边界（与现有系统的接口范围，例：“需与ERP系统、CRM系统对接，同步客户订单数据”）
### 3.3 功能需求（结构化表达）
- 功能模块划分（按业务域拆分，例：“数据采集模块、数据处理模块、可视化分析模块”）
- 每个功能模块的详细需求（按“功能点-输入-处理逻辑-输出-前置条件-后置条件”描述）
- 例：“功能点：销售数据实时同步；输入：ERP系统订单数据；处理逻辑：每5分钟增量同步一次；输出：同步结果日志+数据入库通知；前置条件：ERP系统接口可用；后置条件：数据写入数据仓库”
- 功能优先级（P0必须实现/P1期望实现/P2可选实现）
### 3.4 非功能需求
- 性能需求（响应时间、并发用户数，例：“单接口响应时间≤300ms，支持1000用户并发访问”）
- 可靠性需求（可用性、容错性，例：“系统可用性≥99.9%，数据备份周期≤24小时”）
- 安全性需求（权限控制、数据加密，例：“基于RBAC权限模型，敏感数据传输加密（SSL/TLS）”）
- 易用性需求（操作步骤、培训成本，例：“核心操作步骤≤3步，新用户培训时间≤8小时”）
### 3.5 接口需求
- 内部接口（系统模块间接口，含数据格式、调用方式）
- 外部接口（与现有系统/第三方系统接口，附接口文档链接）
### 3.6 数据需求
- 数据字典（核心数据实体、字段定义、数据类型）
- 数据流转规则（数据采集-处理-存储-展示的全流程）
### 3.7 验收标准
- 功能验收标准（每个P0/P1功能点的验收条件）
- 非功能验收标准（性能/可靠性/安全性的测试指标）
## 关键内容提示
- 功能需求描述需避免模糊表述（如“实现数据统计”→“支持按日/周/月统计销售金额，可导出Excel报表”）
- 非功能需求需量化，符合GB/T 9385-2008中“需求应可验证”的要求
- 关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），确保每个核心需求对应解决一个痛点
## 方法论应用指引
- 瀑布模型结构化需求表达：按“总体-详细-验收”分层，确保需求层层递进、无遗漏
- 冲突处理：若功能需求与非功能需求冲突（如复杂功能导致性能不达标），优先保障核心功能+关键非功能指标，简化非核心功能
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 功能需求：以表格形式呈现（功能模块-功能点-优先级-详细描述-验收标准）
- 页数：控制在20-30页（复杂系统可适当延长）
---
# 4. 项目计划制定模板（支持敏捷迭代计划+瀑布阶段计划双模式）
## 文档目的
明确项目的进度、资源、任务分配、里程碑，为项目执行提供指导
## 核心章节框架（双模式可选）
### 模式A：瀑布模型（阶段计划）
#### 4.1 项目总体计划
- 阶段划分（需求分析→设计→开发→测试→上线→运维交接，每个阶段的起止时间）
- 里程碑计划（关键节点+交付物，例：“需求分析完成（交付物：需求规格说明书）、系统上线（交付物：上线报告）”）
### 4.2 详细任务计划（WBS分解）
- 工作结构分解（按阶段→模块→任务层级拆分，例：“开发阶段→数据采集模块→ERP接口开发任务”）
- 任务分配（RACI矩阵：任务名称-负责人-参与人-审批人-完成时间）
- 依赖关系（任务间的前置/后置依赖，例：“接口开发完成后，方可进行数据测试”）
### 4.3 资源计划
- 人力资源（{{CORE_TEAM}}的详细分工、时间投入占比）
- 物力资源（服务器、软件授权等）
- 预算分配（按阶段/模块分配{{BUDGET_ESTIMATE}}）
### 4.4 沟通计划
- 沟通对象（干系人）
- 沟通方式（会议/邮件/周报）
- 沟通频率（例：“项目例会每周1次，管理层汇报每月1次”）
### 模式B：敏捷模型（迭代计划）
#### 4.1 迭代总体规划
- 迭代周期（{{PROJECT_PERIOD}}，例：“3个迭代，每个迭代4周”）
- 迭代目标（每个迭代的核心交付物，例：“迭代1：完成核心功能开发；迭代2：完成非核心功能+接口对接；迭代3：系统测试+上线准备”）
### 4.2 迭代任务计划（Sprint Backlog）
- 产品待办列表（Product Backlog，按优先级排序）
- 迭代待办列表（Sprint Backlog，每个迭代选取的任务）
- 任务分解（按“故事点”估算工作量，例：“用户登录功能：8个故事点”）
- 每日站会计划（时间/参与人/议题：昨日进展-今日计划-阻塞问题）
### 4.3 迭代评审与回顾计划
- 迭代评审（每个迭代结束后，与干系人确认交付物）
- 迭代回顾（总结经验教训，优化下一轮迭代流程）
### 4.4 资源与沟通计划（同瀑布模型4.3、4.4）
## 关键内容提示
- WBS分解需遵循“8/80原则”（每个任务的工作量≤80小时，≥8小时）
- 敏捷模式中，产品待办列表需由产品经理主导，干系人参与评审
- 两种模式可灵活切换（例：“核心功能采用瀑布阶段计划，优化迭代采用敏捷 Sprint 计划”）
## 方法论应用指引
- 瀑布模式：强调“阶段化、文档化、顺序执行”，适合需求明确、范围稳定的项目
- 敏捷模式：强调“迭代化、增量交付、快速响应变化”，适合需求不确定、需快速验证的项目
- 冲突处理：若进度计划与资源冲突（如核心人员不足），优先保障里程碑任务，调整非核心任务的时间节点
## 输出格式要求
- 进度计划：以甘特图形式呈现（附Excel/Project模板链接）
- 任务分配：RACI矩阵表（角色-任务-责任类型）
- 页数：控制在10-15页
---
# 5. 风险管理计划模板（符合ISO 31000:2018标准+PMP风险矩阵管理逻辑）
## 文档目的
识别项目潜在风险，制定预防与应对措施，降低风险对项目目标的影响
## 核心章节框架
### 5.1 风险管理计划概述
- 风险管理目标（例：“将高风险事件发生概率降低至10%以下，风险损失控制在预算的5%以内”）
- 风险管理流程（风险识别→风险评估→风险应对→风险监控）
- 角色与职责（风险负责人、风险评估团队、干系人职责）
### 5.2 风险识别
- 风险清单（按“技术风险/管理风险/经济风险/外部风险”分类）
- 例：“技术风险：新技术选型失败；管理风险：范围蔓延；经济风险：预算超支；外部风险：政策变化”
- 风险描述（明确风险事件、触发条件、影响范围）
- 风险来源分析（关联项目各阶段：需求/设计/开发/测试/上线）
### 5.3 风险评估（PMP风险矩阵）
- 概率评估（风险发生的可能性：高/中/低，量化为0-10分）
- 影响评估（风险对项目目标的影响程度：高/中/低，量化为0-10分）
- 风险等级计算（风险等级=概率×影响，分为：极高风险/高风险/中风险/低风险）
- 风险优先级排序（按风险等级从高到低排序）
### 5.4 风险应对计划
- 应对策略（按风险等级制定：极高/高风险→规避/转移；中风险→减轻；低风险→接受）
- 例：“极高风险（新技术选型失败）：规避策略→提前进行POC测试，验证技术可行性”
- 具体措施（责任人、执行时间、资源需求）
- 应急计划（风险发生后的补救措施，例：“若技术选型失败，启动备用技术方案，延迟1个迭代周期”）
### 5.5 风险监控与审查
- 监控频率（例：“每周风险审查会议，每月更新风险矩阵”）
- 风险状态跟踪（风险发生状态、应对措施执行效果）
- 风险升级流程（当风险等级上升时，向相关干系人升级的路径）
## 关键内容提示
- 风险识别需覆盖项目全生命周期（从立项到运维交接）
- 风险评估需结合项目实际场景（如500人企业IT项目，“范围蔓延”风险概率较高，需重点防控）
- 应对措施需明确责任人与时间节点，避免“责任不清”
## 方法论应用指引
- PMP风险矩阵管理逻辑：通过“概率-影响”二维评估，聚焦高优先级风险，提高风险管理效率
- ISO 31000:2018标准应用：强调“风险管理的系统性、持续性”，将风险监控融入项目全流程
- 冲突处理：若风险应对措施与成本/进度冲突（如规避高风险需增加预算），优先选择“成本可控+效果明确”的应对方案，必要时调整项目目标
## 输出格式要求
- 风险清单：以风险矩阵表呈现（风险类别-风险描述-概率-影响-风险等级-应对措施-责任人）
- 正文：宋体、小四、1.5倍行距
- 页数：控制在8-12页
---
# 模板使用通用指引
1. 变量替换：所有{{XXX}}变量需替换为项目实际信息，替换后删除变量标记
2. 内容调整：根据项目类型（如数据仓库、业务系统、数字化转型项目）调整各模板的侧重点（例：数据仓库项目需强化“数据需求”“技术可行性”章节）
3. 合规校验：使用前需核对是否符合公司项目管理手册、国家/行业相关标准（如电子政务项目需额外补充“信息安全等级保护”相关内容）
4. 干系人评审：模板填充完成后，需组织核心干系人（管理层、业务部门、IT部门）评审，确保内容一致认可
5. 版本管理：建议按“V1.0（初稿）→V1.1（评审修订）→V2.0（最终版）”进行版本控制，留存修订记录2.1.2 创建立项要素提示词工厂
因为上述立项报告中，需要一些核心需求、当前现状、干系人核心诉求（干系人核心痛点、痒点与燃点），这个可以通过调研报告和录音进行AI提示出关键信息
你现在是一名专业的信息提取分析师，负责从提供的调研报告和访谈录音转录文本中，精准提取立项报告所需的核心信息。请严格按照以下要求执行任务：
<项目名称>
{{PROJECT_NAME}}
</项目名称>
<调研报告>
{{RESEARCH_REPORT}}
</调研报告>
<访谈录音转录文本>
{{INTERVIEW_RECORDING_TRANSCRIPT}}
</访谈录音转录文本>
### 核心提取模块说明（优先级规则：当调研报告与访谈录音内容冲突时，以调研报告信息为准；当不同访谈对象表述冲突时，以多数访谈对象共识或关键决策人表述为准）
你需要从上述材料中提取以下四类关键信息：
#### 1. 核心需求
- 定义：项目需要解决的根本问题或满足的基本要求
- 要求：
- 基于调研报告和访谈内容综合提炼
- 用简洁明确的语言表达
- 每个需求单独编号列出
#### 2. 当前现状
- 定义：项目相关领域的现有状态和实际情况
- 要求：
- 客观描述现有条件和环境
- 区分优势和不足
- 每个现状点单独编号列出
#### 3. 干系人核心诉求
- 定义：项目相关方的关键需求和期望
- 要求：
- 需覆盖项目涉及的所有关键干系方（含不同系统/业务板块对应的关联主体）
- 按不同干系人分类，明确标注干系人所属系统/业务板块（若适用）
- 每个干系人下列出其核心诉求
- 每个诉求单独编号列出
#### 4. 痛点、痒点与燃点
- 定义：干系人在当前情况下的关键感受点
- 痛点：必须解决的问题
- 痒点：期望改进的方面
- 燃点：激发行动的关键因素
- 要求：
- 分别列出痛点、痒点和燃点
- 每个点单独编号列出
### 输出要求
请将提取的信息按照以下结构输出，每个模块使用对应的标签包裹：
<核心需求>
[1] 需求描述1
[2] 需求描述2
...
</核心需求>
<当前现状>
[1] 现状描述1
[2] 现状描述2
...
</当前现状>
<干系人核心诉求>
<干系人名称1（所属系统/板块，若有）>
[1] 诉求描述1
[2] 诉求描述2
...
</干系人名称1（所属系统/板块，若有）>
<干系人名称2（所属系统/板块，若有）>
[1] 诉求描述1
[2] 诉求描述2
...
</干系人名称2（所属系统/板块，若有）>
...
</干系人核心诉求>
<痛点痒点燃点>
<痛点>
[1] 痛点描述1
[2] 痛点描述2
...
</痛点>
<痒点>
[1] 痒点描述1
[2] 痒点描述2
...
</痒点>
<燃点>
[1] 燃点描述1
[2] 燃点描述2
...
</燃点>
</痛点痒点燃点>
### 质量控制要求
1. 所有提取的信息必须直接来自提供的材料，不得添加主观臆断
2. 每个信息点需简洁明了，不超过20个字，且需聚焦立项报告决策关键信息（如核心需求需对应具体业务场景问题，现状需包含数据支撑的关键指标）
3. 确保信息点之间不重复、不重叠
4. 若材料中没有相关信息，请在对应模块中注明"无相关信息"
5. 每个信息点末尾需用括号标注来源，格式为：[来源：调研报告] 或 [来源：访谈录音]
现在开始执行任务，确保输出格式规范、内容准确、信息全面。例如人资系统，我通过需求的萃取和提示词的优化得出结论如下：
# 混凝土行业专业IT系统立项材料（整合多项目管理方法论+合规要求）
## 设计原则说明
1. 合规优先级：国家/行业/企业标准 > 业务目标达成 > 方法论适配性，冲突时按此优先级处理，模板中已标注冲突处理说明
2. 方法论融合逻辑：各模板核心框架基于指定方法论，同时补充跨方法论通用要素（如价值驱动、干系人管理）
3. 模板通用性：支持500人规模企业IT项目（含数字化转型、数据仓库建设、业务系统升级等场景），可通过变量替换适配具体项目
## 核心变量说明（需提前填充）
- {{SYSTEM_NAME}}：人力资源系统
- {{KEY_REQUIREMENTS}}：
[1] 实现组织人事管理线上化与变更追溯 [来源：调研报告]
[2] 打通OA/企微等系统数据同步与对接 [来源：调研报告]
[3] 构建考勤休假全流程线上管理体系 [来源：调研报告]
[4] 实现计时薪资自动化核算与审批 [来源：调研报告]
[5] 优化HR业务审批流程并可视化 [来源：调研报告]
[6] 提供合同/证件等到期预警提醒 [来源：调研报告]
[7] 支持移动办公与关键功能适配 [来源：调研报告]
[8] 补充培训/绩效/招聘等核心模块 [来源：调研报告]
[9] 满足薪资保密与合规风险防控 [来源：调研报告]
[10] 提供人力数据统计分析与看板 [来源：调研报告]
- {{CURRENT_STATUS}}：<当前现状>
[1] 组织架构频繁变更且需细化子公司架构 [来源：调研报告]
[2] 人力与行政职责分工明确但部分交叉 [来源：调研报告]
[3] 现有OA/企微系统未与HR系统完全打通 [来源：调研报告]
[4] 考勤休假有制度但未实现全流程线上化 [来源：调研报告]
[5] 薪资分月薪/计件核算，集团统一审核 [来源：调研报告]
[6] HR审批流程存在但需优化多岗审批 [来源：调研报告]
[7] 部分员工需扫码入职与人证合一认证 [来源：调研报告]
[8] 薪酬构成复杂，含多项补贴与奖惩项 [来源：调研报告]
[9] 现有绩效由运营部管理，未完全线上化 [来源：调研报告]
[10] 缺少统一培训体系与人才发展模块 [来源：调研报告]
</当前现状>
- {{STAKEHOLDER_DEMANDS}}：干系人核心诉求
<干系人核心诉求>
<集团人力部门（集团HR板块）>
[1] 强管控集团及子公司编制与薪酬总额 [来源：调研报告]
[2] 实现薪资核算加密与审批流程规范化 [来源：调研报告]
[3] 需人力数据看板与多维度统计分析 [来源：调研报告]
[4] 要求系统支持二次开发与个性化设置 [来源：调研报告]
</集团人力部门（集团HR板块）>
<子公司综管部（子公司HR板块）>
[1] 门户需显示合同/考勤等待办提醒 [来源：调研报告]
[2] 简化人事异动与薪资调整审批流程 [来源：调研报告]
[3] 需离职交接模板与流程标准化 [来源：调研报告]
[4] 希望考勤异常及时通知与快速处理 [来源：调研报告]
</子公司综管部（子公司HR板块）>
<行政主管（行政板块）>
[1] 需餐饮/宿舍/物资管控基础模块 [来源：调研报告]
[2] 支持私车公用备案与轨迹里程管理 [来源：调研报告]
[3] 实现办公用品定额与台账管理 [来源：调研报告]
</行政主管（行政板块）>
<员工（用户板块）>
[1] 支持扫码入职与电子签确认薪资 [来源：调研报告]
[2] 需移动端请假/加班等流程发起 [来源：调研报告]
[3] 希望工资条线上推送与确认 [来源：调研报告]
</员工（用户板块）>
<财务部门（财务板块）>
[1] 需薪资核算结果及时同步与记账 [来源：调研报告]
[2] 支持个税申报系统对接（可选） [来源：调研报告]
[3] 要求薪资成本分类统计与归集 [来源：调研报告]
</财务部门（财务板块）>
<运营部门（绩效板块）>
[1] 需KPI+GS绩效模型线上化落地 [来源：调研报告]
[2] 支持绩效数据导入与审批流程 [来源：调研报告]
</运营部门（绩效板块）>
</干系人核心诉求>
<痛点痒点燃点>
<痛点>
[1] 多系统数据不同步，需手动录入 [来源：调研报告]
[2] 组织架构变更无完整线上追溯记录 [来源：调研报告]
[3] 薪资核算复杂，易出错且效率低 [来源：调研报告]
[4] 审批流程不清晰，多岗审批划分模糊 [来源：调研报告]
[5] 合同/证件到期无系统自动提醒 [来源：调研报告]
[6] 考勤异常处理与统计汇总繁琐 [来源：调研报告]
[7] 薪资保密难以保障，敏感信息易泄露 [来源：调研报告]
[8] 人事档案分散，查询与维护不便 [来源：调研报告]
</痛点>
<痒点>
[1] 报表格式固定，缺乏自定义能力 [来源：调研报告]
[2] 移动端功能不全，需适配核心流程 [来源：调研报告]
[3] 培训体系缺失，线上学习需求未满足 [来源：调研报告]
[4] 人才库与绩效盘点无标准线上模型 [来源：调研报告]
[5] 离职证明等函件需手动推送OA [来源：调研报告]
[6] 补卡次数限制与扣款规则需线上化 [来源：调研报告]
</痒点>
<燃点>
[1] 企业数字化转型，需打通数据壁垒 [来源：调研报告]
[2] 劳资纠纷风险，需合规流程与台账 [来源：调研报告]
[3] 组织规模扩大，人工管理效率不足 [来源：调研报告]
[4] 薪资保密要求严格，需分级权限控制 [来源：调研报告]
[5] 行业特殊工时制度，需系统适配支持 [来源：调研报告]
</燃点>
</痛点痒点燃点>
- {{PROJECT_PERIOD}}：项目预计周期：3个月上线：组织、人事、招聘、薪酬，后3个月上线绩效
- {{BUDGET_ESTIMATE}}：项目预估预算（例：“500万元”“年度IT预算的20%”）
- {{CORE_TEAM}}：核心项目团队成员及角色（例：“项目经理1名、产品经理1名、开发工程师5名、测试工程师2名、业务顾问2名”）
---
# 1. 项目建议书模板（基于PMP商业论证框架+国家电子政务工程立项要求）
## 文档目的
明确项目立项的商业价值、必要性、预期收益，为立项审批提供核心依据
## 核心章节框架
### 1.1 项目背景与意义
- 行业政策背景（如数字化转型相关政策、监管要求）
- 企业业务发展需求（关联{{CURRENT_STATUS}}中的瓶颈）
- 项目与企业战略的对齐关系
### 1.2 现状分析与问题诊断
- 当前业务流程描述（附流程图建议）
- 现有系统支撑不足（技术/功能/效率层面）
- 问题影响范围与严重程度（量化数据支撑）
### 1.3 项目目标与核心需求
- 总体目标（符合SMART原则，关联{{KEY_REQUIREMENTS}}）
- 分阶段目标（短期/中期/长期）
- 核心需求清单（按优先级排序，标注“必须实现”“期望实现”）
### 1.4 商业论证与预期收益
- 定量收益（ROI测算：投资回报率=（预期收益-投入成本）/投入成本×100%；例：“预计3年累计收益1200万元，ROI达140%”）
- 直接收益：成本节约（人力/物力/时间）、收入增长
- 间接收益：效率提升、风险降低、客户满意度提升
- 定性收益（如合规性提升、竞争力增强、组织能力建设）
### 1.5 项目初步规划
- 项目周期预估（{{PROJECT_PERIOD}}）
- 预算预估（{{BUDGET_ESTIMATE}}）
- 核心团队构成（{{CORE_TEAM}}）
### 1.6 立项必要性结论
- 问题解决的紧迫性
- 商业价值的不可替代性
- 与企业战略的契合度总结
## 关键内容提示
- 所有收益需关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），说明如何解决痛点
- 引用国家电子政务工程建设项目管理暂行办法中立项要求的核心条款（如“符合国家信息化发展规划”“具备明确的业务需求和应用场景”）
- 附相关支撑材料（如政策文件截图、现有系统问题统计数据）
## 方法论应用指引
- PMP商业论证框架应用：聚焦“商业价值可行性”，通过收益测算、风险评估支撑立项决策
- 冲突处理：若商业价值与短期成本冲突，优先强调长期战略价值，补充分阶段投入方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 核心数据：以表格/图表形式呈现（如ROI测算表、收益对比图）
- 页数：控制在10-15页
---
# 2. 可行性分析报告模板（融合PRINCE2可行性评估维度+企业IT项目可行性指南）
## 文档目的
从技术、经济、管理、操作四个维度评估项目可行性，为项目决策提供科学依据
## 核心章节框架
### 2.1 项目概述
- 项目目标、范围（与项目建议书一致）
- 核心需求摘要（{{KEY_REQUIREMENTS}}）
### 2.2 技术可行性分析（PRINCE2核心维度）
- 技术选型方案（硬件/软件/架构，例：“云原生架构+微服务部署，适配AWS/Azure国内版”）
- 技术成熟度评估（是否为行业主流技术，风险等级）
- 现有技术团队能力匹配度（需补充培训/外包的，说明方案）
- 技术兼容性（与现有系统集成方案，接口标准化程度）
- 技术风险及应对措施（例：“新技术引入风险，通过POC验证降低”）
### 2.3 经济可行性分析（PRINCE2核心维度）
- 投资估算（明细：硬件采购、软件授权、开发实施、培训、运维等）
- 成本效益分析（ROI、投资回收期测算，参考项目建议书）
- 资金来源与保障（{{BUDGET_ESTIMATE}}的落实情况）
- 成本控制措施（例：“通过敏捷迭代控制范围蔓延，降低额外成本”）
### 2.4 管理可行性分析（PRINCE2核心维度）
- 项目组织架构（RACI矩阵：明确干系人角色与职责，例：“项目经理：负责整体协调（R）；业务部门负责人：审批需求（A）；开发团队：执行开发（C）”）
- 项目管理制度（参考公司项目管理手册，如变更管理、沟通管理流程）
- 干系人支持程度（管理层/业务部门/IT部门的配合意愿）
### 2.5 操作可行性分析（PRINCE2核心维度）
- 业务流程适配性（新系统对现有业务流程的影响，是否需要优化）
- 用户接受度评估（终端用户技能水平，是否需要培训）
- 运维保障能力（IT运维团队能否支撑系统上线后的运维需求）
### 2.6 可行性结论与建议
- 综合可行性评级（高/中/低）
- 立项建议（建议立项/暂缓立项/调整方案后立项）
- 后续工作推进计划
## 关键内容提示
- 技术可行性需附POC测试计划（若涉及新技术）
- 经济可行性需对比“实施项目”与“不实施项目”的成本差异
- 参考《企业IT项目可行性研究指南》中的评估指标（如技术成熟度≥3级、ROI≥80%等）
## 方法论应用指引
- PRINCE2可行性评估维度：覆盖“技术-经济-管理-操作”四维，确保评估全面性
- 冲突处理：若技术可行性与经济可行性冲突（如新技术成本过高），优先选择“成本可控+满足核心需求”的替代技术方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 分析结果：以评估矩阵表呈现（如技术可行性评估矩阵：技术点-成熟度-风险等级-应对措施）
- 页数：控制在15-20页
---
# 3. 需求规格说明书框架（符合GB/T 9385-2008规范+瀑布模型结构化需求表达）
## 文档目的
明确系统的功能需求、非功能需求、接口需求等，为开发、测试、验收提供依据
## 核心章节框架
### 3.1 引言
- 文档目的与适用范围
- 术语定义、缩写说明
- 参考文档（如项目建议书、可行性分析报告）
### 3.2 总体描述
- 系统目标（与项目建议书一致）
- 运行环境（硬件/软件/网络环境，例：“服务器：8核16G，操作系统：CentOS 7.0，数据库：MySQL 8.0”）
- 系统边界（与现有系统的接口范围，例：“需与ERP系统、CRM系统对接，同步客户订单数据”）
### 3.3 功能需求（结构化表达）
- 功能模块划分（按业务域拆分，例：“数据采集模块、数据处理模块、可视化分析模块”）
- 每个功能模块的详细需求（按“功能点-输入-处理逻辑-输出-前置条件-后置条件”描述）
- 例：“功能点：销售数据实时同步；输入：ERP系统订单数据；处理逻辑：每5分钟增量同步一次；输出：同步结果日志+数据入库通知；前置条件：ERP系统接口可用；后置条件：数据写入数据仓库”
- 功能优先级（P0必须实现/P1期望实现/P2可选实现）
### 3.4 非功能需求
- 性能需求（响应时间、并发用户数，例：“单接口响应时间≤300ms，支持1000用户并发访问”）
- 可靠性需求（可用性、容错性，例：“系统可用性≥99.9%，数据备份周期≤24小时”）
- 安全性需求（权限控制、数据加密，例：“基于RBAC权限模型，敏感数据传输加密（SSL/TLS）”）
- 易用性需求（操作步骤、培训成本，例：“核心操作步骤≤3步，新用户培训时间≤8小时”）
### 3.5 接口需求
- 内部接口（系统模块间接口，含数据格式、调用方式）
- 外部接口（与现有系统/第三方系统接口，附接口文档链接）
### 3.6 数据需求
- 数据字典（核心数据实体、字段定义、数据类型）
- 数据流转规则（数据采集-处理-存储-展示的全流程）
### 3.7 验收标准
- 功能验收标准（每个P0/P1功能点的验收条件）
- 非功能验收标准（性能/可靠性/安全性的测试指标）
## 关键内容提示
- 功能需求描述需避免模糊表述（如“实现数据统计”→“支持按日/周/月统计销售金额，可导出Excel报表”）
- 非功能需求需量化，符合GB/T 9385-2008中“需求应可验证”的要求
- 关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），确保每个核心需求对应解决一个痛点
## 方法论应用指引
- 瀑布模型结构化需求表达：按“总体-详细-验收”分层，确保需求层层递进、无遗漏
- 冲突处理：若功能需求与非功能需求冲突（如复杂功能导致性能不达标），优先保障核心功能+关键非功能指标，简化非核心功能
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 功能需求：以表格形式呈现（功能模块-功能点-优先级-详细描述-验收标准）
- 页数：控制在20-30页（复杂系统可适当延长）
---
# 4. 项目计划制定模板（支持敏捷迭代计划+瀑布阶段计划双模式）
## 文档目的
明确项目的进度、资源、任务分配、里程碑，为项目执行提供指导
## 核心章节框架（双模式可选）
### 模式A：瀑布模型（阶段计划）
#### 4.1 项目总体计划
- 阶段划分（需求分析→设计→开发→测试→上线→运维交接，每个阶段的起止时间）
- 里程碑计划（关键节点+交付物，例：“需求分析完成（交付物：需求规格说明书）、系统上线（交付物：上线报告）”）
### 4.2 详细任务计划（WBS分解）
- 工作结构分解（按阶段→模块→任务层级拆分，例：“开发阶段→数据采集模块→ERP接口开发任务”）
- 任务分配（RACI矩阵：任务名称-负责人-参与人-审批人-完成时间）
- 依赖关系（任务间的前置/后置依赖，例：“接口开发完成后，方可进行数据测试”）
### 4.3 资源计划
- 人力资源（{{CORE_TEAM}}的详细分工、时间投入占比）
- 物力资源（服务器、软件授权等）
- 预算分配（按阶段/模块分配{{BUDGET_ESTIMATE}}）
### 4.4 沟通计划
- 沟通对象（干系人）
- 沟通方式（会议/邮件/周报）
- 沟通频率（例：“项目例会每周1次，管理层汇报每月1次”）
### 模式B：敏捷模型（迭代计划）
#### 4.1 迭代总体规划
- 迭代周期（{{PROJECT_PERIOD}}，例：“3个迭代，每个迭代4周”）
- 迭代目标（每个迭代的核心交付物，例：“迭代1：完成核心功能开发；迭代2：完成非核心功能+接口对接；迭代3：系统测试+上线准备”）
### 4.2 迭代任务计划（Sprint Backlog）
- 产品待办列表（Product Backlog，按优先级排序）
- 迭代待办列表（Sprint Backlog，每个迭代选取的任务）
- 任务分解（按“故事点”估算工作量，例：“用户登录功能：8个故事点”）
- 每日站会计划（时间/参与人/议题：昨日进展-今日计划-阻塞问题）
### 4.3 迭代评审与回顾计划
- 迭代评审（每个迭代结束后，与干系人确认交付物）
- 迭代回顾（总结经验教训，优化下一轮迭代流程）
### 4.4 资源与沟通计划（同瀑布模型4.3、4.4）
## 关键内容提示
- WBS分解需遵循“8/80原则”（每个任务的工作量≤80小时，≥8小时）
- 敏捷模式中，产品待办列表需由产品经理主导，干系人参与评审
- 两种模式可灵活切换（例：“核心功能采用瀑布阶段计划，优化迭代采用敏捷 Sprint 计划”）
## 方法论应用指引
- 瀑布模式：强调“阶段化、文档化、顺序执行”，适合需求明确、范围稳定的项目
- 敏捷模式：强调“迭代化、增量交付、快速响应变化”，适合需求不确定、需快速验证的项目
- 冲突处理：若进度计划与资源冲突（如核心人员不足），优先保障里程碑任务，调整非核心任务的时间节点
## 输出格式要求
- 进度计划：以甘特图形式呈现（附Excel/Project模板链接）
- 任务分配：RACI矩阵表（角色-任务-责任类型）
- 页数：控制在10-15页
---
# 5. 风险管理计划模板（符合ISO 31000:2018标准+PMP风险矩阵管理逻辑）
## 文档目的
识别项目潜在风险，制定预防与应对措施，降低风险对项目目标的影响
## 核心章节框架
### 5.1 风险管理计划概述
- 风险管理目标（例：“将高风险事件发生概率降低至10%以下，风险损失控制在预算的5%以内”）
- 风险管理流程（风险识别→风险评估→风险应对→风险监控）
- 角色与职责（风险负责人、风险评估团队、干系人职责）
### 5.2 风险识别
- 风险清单（按“技术风险/管理风险/经济风险/外部风险”分类）
- 例：“技术风险：新技术选型失败；管理风险：范围蔓延；经济风险：预算超支；外部风险：政策变化”
- 风险描述（明确风险事件、触发条件、影响范围）
- 风险来源分析（关联项目各阶段：需求/设计/开发/测试/上线）
### 5.3 风险评估（PMP风险矩阵）
- 概率评估（风险发生的可能性：高/中/低，量化为0-10分）
- 影响评估（风险对项目目标的影响程度：高/中/低，量化为0-10分）
- 风险等级计算（风险等级=概率×影响，分为：极高风险/高风险/中风险/低风险）
- 风险优先级排序（按风险等级从高到低排序）
### 5.4 风险应对计划
- 应对策略（按风险等级制定：极高/高风险→规避/转移；中风险→减轻；低风险→接受）
- 例：“极高风险（新技术选型失败）：规避策略→提前进行POC测试，验证技术可行性”
- 具体措施（责任人、执行时间、资源需求）
- 应急计划（风险发生后的补救措施，例：“若技术选型失败，启动备用技术方案，延迟1个迭代周期”）
### 5.5 风险监控与审查
- 监控频率（例：“每周风险审查会议，每月更新风险矩阵”）
- 风险状态跟踪（风险发生状态、应对措施执行效果）
- 风险升级流程（当风险等级上升时，向相关干系人升级的路径）
## 关键内容提示
- 风险识别需覆盖项目全生命周期（从立项到运维交接）
- 风险评估需结合项目实际场景（如500人企业IT项目，“范围蔓延”风险概率较高，需重点防控）
- 应对措施需明确责任人与时间节点，避免“责任不清”
## 方法论应用指引
- PMP风险矩阵管理逻辑：通过“概率-影响”二维评估，聚焦高优先级风险，提高风险管理效率
- ISO 31000:2018标准应用：强调“风险管理的系统性、持续性”，将风险监控融入项目全流程
- 冲突处理：若风险应对措施与成本/进度冲突（如规避高风险需增加预算），优先选择“成本可控+效果明确”的应对方案，必要时调整项目目标
- 风险清单：以风险矩阵表呈现（风险类别-风险描述-概率-影响-风险等级-应对措施-责任人）你根据我提供的调研问卷，完善以下提示词的补充，最终
# 专业IT系统立项材料（整合多项目管理方法论+合规要求）
## 设计原则说明
1. 合规优先级：国家/行业/企业标准 > 业务目标达成 > 方法论适配性，冲突时按此优先级处理，模板中已标注冲突处理说明
2. 方法论融合逻辑：各模板核心框架基于指定方法论，同时补充跨方法论通用要素（如价值驱动、干系人管理）
3. 模板通用性：支持500人规模企业IT项目（含数字化转型、数据仓库建设、业务系统升级等场景），可通过变量替换适配具体项目
## 核心变量说明（需提前填充）
- {{SYSTEM_NAME}}：人力资源系统
- {{KEY_REQUIREMENTS}}：
[1] 实现组织人事管理线上化与变更追溯 [来源：调研报告]
[2] 打通OA/企微等系统数据同步与对接 [来源：调研报告]
[3] 构建考勤休假全流程线上管理体系 [来源：调研报告]
[4] 实现计时薪资自动化核算与审批 [来源：调研报告]
[5] 优化HR业务审批流程并可视化 [来源：调研报告]
[6] 提供合同/证件等到期预警提醒 [来源：调研报告]
[7] 支持移动办公与关键功能适配 [来源：调研报告]
[8] 补充培训/绩效/招聘等核心模块 [来源：调研报告]
[9] 满足薪资保密与合规风险防控 [来源：调研报告]
[10] 提供人力数据统计分析与看板 [来源：调研报告]
- {{CURRENT_STATUS}}：<当前现状>
[1] 组织架构频繁变更且需细化子公司架构 [来源：调研报告]
[2] 人力与行政职责分工明确但部分交叉 [来源：调研报告]
[3] 现有OA/企微系统未与HR系统完全打通 [来源：调研报告]
[4] 考勤休假有制度但未实现全流程线上化 [来源：调研报告]
[5] 薪资分月薪/计件核算，集团统一审核 [来源：调研报告]
[6] HR审批流程存在但需优化多岗审批 [来源：调研报告]
[7] 部分员工需扫码入职与人证合一认证 [来源：调研报告]
[8] 薪酬构成复杂，含多项补贴与奖惩项 [来源：调研报告]
[9] 现有绩效由运营部管理，未完全线上化 [来源：调研报告]
[10] 缺少统一培训体系与人才发展模块 [来源：调研报告]
</当前现状>
- {{STAKEHOLDER_DEMANDS}}：干系人核心诉求
<干系人核心诉求>
<集团人力部门（集团HR板块）>
[1] 强管控集团及子公司编制与薪酬总额 [来源：调研报告]
[2] 实现薪资核算加密与审批流程规范化 [来源：调研报告]
[3] 需人力数据看板与多维度统计分析 [来源：调研报告]
[4] 要求系统支持二次开发与个性化设置 [来源：调研报告]
</集团人力部门（集团HR板块）>
<子公司综管部（子公司HR板块）>
[1] 门户需显示合同/考勤等待办提醒 [来源：调研报告]
[2] 简化人事异动与薪资调整审批流程 [来源：调研报告]
[3] 需离职交接模板与流程标准化 [来源：调研报告]
[4] 希望考勤异常及时通知与快速处理 [来源：调研报告]
</子公司综管部（子公司HR板块）>
<行政主管（行政板块）>
[1] 需餐饮/宿舍/物资管控基础模块 [来源：调研报告]
[2] 支持私车公用备案与轨迹里程管理 [来源：调研报告]
[3] 实现办公用品定额与台账管理 [来源：调研报告]
</行政主管（行政板块）>
<员工（用户板块）>
[1] 支持扫码入职与电子签确认薪资 [来源：调研报告]
[2] 需移动端请假/加班等流程发起 [来源：调研报告]
[3] 希望工资条线上推送与确认 [来源：调研报告]
</员工（用户板块）>
<财务部门（财务板块）>
[1] 需薪资核算结果及时同步与记账 [来源：调研报告]
[2] 支持个税申报系统对接（可选） [来源：调研报告]
[3] 要求薪资成本分类统计与归集 [来源：调研报告]
</财务部门（财务板块）>
<运营部门（绩效板块）>
[1] 需KPI+GS绩效模型线上化落地 [来源：调研报告]
[2] 支持绩效数据导入与审批流程 [来源：调研报告]
</运营部门（绩效板块）>
</干系人核心诉求>
<痛点痒点燃点>
<痛点>
[1] 多系统数据不同步，需手动录入 [来源：调研报告]
[2] 组织架构变更无完整线上追溯记录 [来源：调研报告]
[3] 薪资核算复杂，易出错且效率低 [来源：调研报告]
[4] 审批流程不清晰，多岗审批划分模糊 [来源：调研报告]
[5] 合同/证件到期无系统自动提醒 [来源：调研报告]
[6] 考勤异常处理与统计汇总繁琐 [来源：调研报告]
[7] 薪资保密难以保障，敏感信息易泄露 [来源：调研报告]
[8] 人事档案分散，查询与维护不便 [来源：调研报告]
</痛点>
<痒点>
[1] 报表格式固定，缺乏自定义能力 [来源：调研报告]
[2] 移动端功能不全，需适配核心流程 [来源：调研报告]
[3] 培训体系缺失，线上学习需求未满足 [来源：调研报告]
[4] 人才库与绩效盘点无标准线上模型 [来源：调研报告]
[5] 离职证明等函件需手动推送OA [来源：调研报告]
[6] 补卡次数限制与扣款规则需线上化 [来源：调研报告]
</痒点>
<燃点>
[1] 企业数字化转型，需打通数据壁垒 [来源：调研报告]
[2] 劳资纠纷风险，需合规流程与台账 [来源：调研报告]
[3] 组织规模扩大，人工管理效率不足 [来源：调研报告]
[4] 薪资保密要求严格，需分级权限控制 [来源：调研报告]
[5] 行业特殊工时制度，需系统适配支持 [来源：调研报告]
</燃点>
</痛点痒点燃点>
- {{PROJECT_PERIOD}}：项目预计周期：3个月上线：组织、人事、招聘、薪酬，后3个月上线绩效
- {{BUDGET_ESTIMATE}}：项目预估预算（例：“500万元”“年度IT预算的20%”）
- {{CORE_TEAM}}：核心项目团队成员及角色（例：“项目经理1名、产品经理1名、开发工程师5名、测试工程师2名、业务顾问2名”）
---
# 1. 项目建议书模板（基于PMP商业论证框架+国家电子政务工程立项要求）
## 文档目的
明确项目立项的商业价值、必要性、预期收益，为立项审批提供核心依据
## 核心章节框架
### 1.1 项目背景与意义
- 行业政策背景（如数字化转型相关政策、监管要求）
- 企业业务发展需求（关联{{CURRENT_STATUS}}中的瓶颈）
- 项目与企业战略的对齐关系
### 1.2 现状分析与问题诊断
- 当前业务流程描述（附流程图建议）
- 现有系统支撑不足（技术/功能/效率层面）
- 问题影响范围与严重程度（量化数据支撑）
### 1.3 项目目标与核心需求
- 总体目标（符合SMART原则，关联{{KEY_REQUIREMENTS}}）
- 分阶段目标（短期/中期/长期）
- 核心需求清单（按优先级排序，标注“必须实现”“期望实现”）
### 1.4 商业论证与预期收益
- 定量收益（ROI测算：投资回报率=（预期收益-投入成本）/投入成本×100%；例：“预计3年累计收益1200万元，ROI达140%”）
- 直接收益：成本节约（人力/物力/时间）、收入增长
- 间接收益：效率提升、风险降低、客户满意度提升
- 定性收益（如合规性提升、竞争力增强、组织能力建设）
### 1.5 项目初步规划
- 项目周期预估：3个月实施组织人事考勤薪酬，再3个月上线绩效
- 预算预估：40万一期，20万二期
- 核心团队构成：内部人员：集团总经理作为项目总监、总经办主任（项目经理）、IT技术项目经理、老板的女儿作为项目助理、人资外包服务团队（负责除核算薪酬外所有人事板块工作）、人资内部主管（负责薪酬核算和协助人事板块工作）、IT技术人员*2
### 1.6 立项必要性结论
- 问题解决的紧迫性
- 商业价值的不可替代性
- 与企业战略的契合度总结
## 关键内容提示
- 所有收益需关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），说明如何解决痛点
- 引用国家电子政务工程建设项目管理暂行办法中立项要求的核心条款（如“符合国家信息化发展规划”“具备明确的业务需求和应用场景”）
- 附相关支撑材料（如政策文件截图、现有系统问题统计数据）
## 方法论应用指引
- PMP商业论证框架应用：聚焦“商业价值可行性”，通过收益测算、风险评估支撑立项决策
- 冲突处理：若商业价值与短期成本冲突，优先强调长期战略价值，补充分阶段投入方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 核心数据：以表格/图表形式呈现（如ROI测算表、收益对比图）
- 页数：控制在10-15页
---
# 2. 可行性分析报告模板（融合PRINCE2可行性评估维度+企业IT项目可行性指南）
## 文档目的
从技术、经济、管理、操作四个维度评估项目可行性，为项目决策提供科学依据
## 核心章节框架
### 2.1 项目概述
- 项目目标、范围（与项目建议书一致）
- 核心需求摘要（{{KEY_REQUIREMENTS}}）
### 2.2 技术可行性分析（PRINCE2核心维度）
- 技术选型方案（硬件/软件/架构，例：“云原生架构+微服务部署，适配AWS/Azure国内版”）
- 技术成熟度评估（是否为行业主流技术，风险等级）
- 现有技术团队能力匹配度（需补充培训/外包的，说明方案）
- 技术兼容性（与现有系统集成方案，接口标准化程度）
- 技术风险及应对措施（例：“新技术引入风险，通过POC验证降低”）
### 2.3 经济可行性分析（PRINCE2核心维度）
- 投资估算（明细：硬件采购、软件授权、开发实施、培训、运维等）
- 成本效益分析（ROI、投资回收期测算，参考项目建议书）
- 资金来源与保障（{{BUDGET_ESTIMATE}}的落实情况）
- 成本控制措施（例：“通过敏捷迭代控制范围蔓延，降低额外成本”）
### 2.4 管理可行性分析（PRINCE2核心维度）
- 项目组织架构（RACI矩阵：明确干系人角色与职责，例：“项目经理：负责整体协调（R）；业务部门负责人：审批需求（A）；开发团队：执行开发（C）”）
- 项目管理制度（参考公司项目管理手册，如变更管理、沟通管理流程）
- 干系人支持程度（管理层/业务部门/IT部门的配合意愿）
### 2.5 操作可行性分析（PRINCE2核心维度）
- 业务流程适配性（新系统对现有业务流程的影响，是否需要优化）
- 用户接受度评估（终端用户技能水平，是否需要培训）
- 运维保障能力（IT运维团队能否支撑系统上线后的运维需求）
### 2.6 可行性结论与建议
- 综合可行性评级（高/中/低）
- 立项建议（建议立项/暂缓立项/调整方案后立项）
- 后续工作推进计划
## 关键内容提示
- 技术可行性需附POC测试计划（若涉及新技术）
- 经济可行性需对比“实施项目”与“不实施项目”的成本差异
- 参考《企业IT项目可行性研究指南》中的评估指标（如技术成熟度≥3级、ROI≥80%等）
## 方法论应用指引
- PRINCE2可行性评估维度：覆盖“技术-经济-管理-操作”四维，确保评估全面性
- 冲突处理：若技术可行性与经济可行性冲突（如新技术成本过高），优先选择“成本可控+满足核心需求”的替代技术方案
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 分析结果：以评估矩阵表呈现（如技术可行性评估矩阵：技术点-成熟度-风险等级-应对措施）
- 页数：控制在15-20页
---
# 3. 需求规格说明书框架（符合GB/T 9385-2008规范+瀑布模型结构化需求表达）
## 文档目的
明确系统的功能需求、非功能需求、接口需求等，为开发、测试、验收提供依据
## 核心章节框架
### 3.1 引言
- 文档目的与适用范围
- 术语定义、缩写说明
- 参考文档（如项目建议书、可行性分析报告）
### 3.2 总体描述
- 系统目标（与项目建议书一致）
- 运行环境（硬件/软件/网络环境，例：“服务器：8核16G，操作系统：CentOS 7.0，数据库：MySQL 8.0”）
- 系统边界（与现有系统的接口范围，例：“需与ERP系统、CRM系统对接，同步客户订单数据”）
### 3.3 功能需求（结构化表达）
- 功能模块划分（按业务域拆分，例：“数据采集模块、数据处理模块、可视化分析模块”）
- 每个功能模块的详细需求（按“功能点-输入-处理逻辑-输出-前置条件-后置条件”描述）
- 例：“功能点：销售数据实时同步；输入：ERP系统订单数据；处理逻辑：每5分钟增量同步一次；输出：同步结果日志+数据入库通知；前置条件：ERP系统接口可用；后置条件：数据写入数据仓库”
- 功能优先级（P0必须实现/P1期望实现/P2可选实现）
### 3.4 非功能需求
- 性能需求（响应时间、并发用户数，例：“单接口响应时间≤300ms，支持1000用户并发访问”）
- 可靠性需求（可用性、容错性，例：“系统可用性≥99.9%，数据备份周期≤24小时”）
- 安全性需求（权限控制、数据加密，例：“基于RBAC权限模型，敏感数据传输加密（SSL/TLS）”）
- 易用性需求（操作步骤、培训成本，例：“核心操作步骤≤3步，新用户培训时间≤8小时”）
### 3.5 接口需求
- 内部接口（系统模块间接口，含数据格式、调用方式）
- 外部接口（与现有系统/第三方系统接口，附接口文档链接）
### 3.6 数据需求
- 数据字典（核心数据实体、字段定义、数据类型）
- 数据流转规则（数据采集-处理-存储-展示的全流程）
### 3.7 验收标准
- 功能验收标准（每个P0/P1功能点的验收条件）
- 非功能验收标准（性能/可靠性/安全性的测试指标）
## 关键内容提示
- 功能需求描述需避免模糊表述（如“实现数据统计”→“支持按日/周/月统计销售金额，可导出Excel报表”）
- 非功能需求需量化，符合GB/T 9385-2008中“需求应可验证”的要求
- 关联干系人诉求（{{STAKEHOLDER_DEMANDS}}），确保每个核心需求对应解决一个痛点
## 方法论应用指引
- 瀑布模型结构化需求表达：按“总体-详细-验收”分层，确保需求层层递进、无遗漏
- 冲突处理：若功能需求与非功能需求冲突（如复杂功能导致性能不达标），优先保障核心功能+关键非功能指标，简化非核心功能
## 输出格式要求
- 正文：宋体、小四、1.5倍行距
- 功能需求：以表格形式呈现（功能模块-功能点-优先级-详细描述-验收标准）
- 页数：控制在20-30页（复杂系统可适当延长）
---
# 4. 项目计划制定模板（支持敏捷迭代计划+瀑布阶段计划双模式）
## 文档目的
明确项目的进度、资源、任务分配、里程碑，为项目执行提供指导
## 核心章节框架（双模式可选）
### 模式A：瀑布模型（阶段计划）
#### 4.1 项目总体计划
- 阶段划分（需求分析→设计→开发→测试→上线→运维交接，每个阶段的起止时间）
- 里程碑计划（关键节点+交付物，例：“需求分析完成（交付物：需求规格说明书）、系统上线（交付物：上线报告）”）
### 4.2 详细任务计划（WBS分解）
- 工作结构分解（按阶段→模块→任务层级拆分，例：“开发阶段→数据采集模块→ERP接口开发任务”）
- 任务分配（RACI矩阵：任务名称-负责人-参与人-审批人-完成时间）
- 依赖关系（任务间的前置/后置依赖，例：“接口开发完成后，方可进行数据测试”）
### 4.3 资源计划
- 人力资源（{{CORE_TEAM}}的详细分工、时间投入占比）
- 物力资源（服务器、软件授权等）
- 预算分配（按阶段/模块分配{{BUDGET_ESTIMATE}}）
### 4.4 沟通计划
- 沟通对象（干系人）
- 沟通方式（会议/邮件/周报）
- 沟通频率（例：“项目例会每周1次，管理层汇报每月1次”）
### 模式B：敏捷模型（迭代计划）
#### 4.1 迭代总体规划
- 迭代周期（{{PROJECT_PERIOD}}，例：“3个迭代，每个迭代4周”）
- 迭代目标（每个迭代的核心交付物，例：“迭代1：完成核心功能开发；迭代2：完成非核心功能+接口对接；迭代3：系统测试+上线准备”）
### 4.2 迭代任务计划（Sprint Backlog）
- 产品待办列表（Product Backlog，按优先级排序）
- 迭代待办列表（Sprint Backlog，每个迭代选取的任务）
- 任务分解（按“故事点”估算工作量，例：“用户登录功能：8个故事点”）
- 每日站会计划（时间/参与人/议题：昨日进展-今日计划-阻塞问题）
### 4.3 迭代评审与回顾计划
- 迭代评审（每个迭代结束后，与干系人确认交付物）
- 迭代回顾（总结经验教训，优化下一轮迭代流程）
### 4.4 资源与沟通计划（同瀑布模型4.3、4.4）
## 关键内容提示
- WBS分解需遵循“8/80原则”（每个任务的工作量≤80小时，≥8小时）
- 敏捷模式中，产品待办列表需由产品经理主导，干系人参与评审
- 两种模式可灵活切换（例：“核心功能采用瀑布阶段计划，优化迭代采用敏捷 Sprint 计划”）
## 方法论应用指引
- 瀑布模式：强调“阶段化、文档化、顺序执行”，适合需求明确、范围稳定的项目
- 敏捷模式：强调“迭代化、增量交付、快速响应变化”，适合需求不确定、需快速验证的项目
- 冲突处理：若进度计划与资源冲突（如核心人员不足），优先保障里程碑任务，调整非核心任务的时间节点
## 输出格式要求
- 进度计划：以甘特图形式呈现（附Excel/Project模板链接）
- 任务分配：RACI矩阵表（角色-任务-责任类型）
- 页数：控制在10-15页
---
# 5. 风险管理计划模板（符合ISO 31000:2018标准+PMP风险矩阵管理逻辑）
## 文档目的
识别项目潜在风险，制定预防与应对措施，降低风险对项目目标的影响
## 核心章节框架
### 5.1 风险管理计划概述
- 风险管理目标（例：“将高风险事件发生概率降低至10%以下，风险损失控制在预算的5%以内”）
- 风险管理流程（风险识别→风险评估→风险应对→风险监控）
- 角色与职责（风险负责人、风险评估团队、干系人职责）
### 5.2 风险识别
- 风险清单（按“技术风险/管理风险/经济风险/外部风险”分类）
- 例：“技术风险：新技术选型失败；管理风险：范围蔓延；经济风险：预算超支；外部风险：政策变化”
- 风险描述（明确风险事件、触发条件、影响范围）
- 风险来源分析（关联项目各阶段：需求/设计/开发/测试/上线）
### 5.3 风险评估（PMP风险矩阵）
- 概率评估（风险发生的可能性：高/中/低，量化为0-10分）
- 影响评估（风险对项目目标的影响程度：高/中/低，量化为0-10分）
- 风险等级计算（风险等级=概率×影响，分为：极高风险/高风险/中风险/低风险）
- 风险优先级排序（按风险等级从高到低排序）
### 5.4 风险应对计划
- 应对策略（按风险等级制定：极高/高风险→规避/转移；中风险→减轻；低风险→接受）
- 例：“极高风险（新技术选型失败）：规避策略→提前进行POC测试，验证技术可行性”
- 具体措施（责任人、执行时间、资源需求）
- 应急计划（风险发生后的补救措施，例：“若技术选型失败，启动备用技术方案，延迟1个迭代周期”）
### 5.5 风险监控与审查
- 监控频率（例：“每周风险审查会议，每月更新风险矩阵”）
- 风险状态跟踪（风险发生状态、应对措施执行效果）
- 风险升级流程（当风险等级上升时，向相关干系人升级的路径）
## 关键内容提示
- 风险识别需覆盖项目全生命周期（从立项到运维交接）
- 风险评估需结合项目实际场景（如500人企业IT项目，“范围蔓延”风险概率较高，需重点防控）
- 应对措施需明确责任人与时间节点，避免“责任不清”
## 方法论应用指引
- PMP风险矩阵管理逻辑：通过“概率-影响”二维评估，聚焦高优先级风险，提高风险管理效率
- ISO 31000:2018标准应用：强调“风险管理的系统性、持续性”，将风险监控融入项目全流程
- 冲突处理：若风险应对措施与成本/进度冲突（如规避高风险需增加预算），优先选择“成本可控+效果明确”的应对方案，必要时调整项目目标
- 风险清单：以风险矩阵表呈现（风险类别-风险描述-概率-影响-风险等级-应对措施-责任人）下一步，我们通过豆包、qianwen和metaso等进行深入研究
豆包：https://www.doubao.com/chat/
metaso:https://metaso.cn
qianwen:https://qianwen.com/
然后就能输出一份研究报告，如下：
然后我们可以把输出的研究报告给Gamma来生成PPT
也可以通过https://www.genspark.ai 来创建PPT
二、通过AI进行报表分析
2.1 下载Trae软件并创建项目
下载和安装这部分忽略
2.2 数据理解
Step1:
/Users/smastars/Desktop/trae_projects/test/非主材采购/下有关于采购很多数据，你做一下所有数据的摸底，全面地毯式排查，我需要你帮我做深度数据分析
STEP2:
请地毯式地做数据表的单维度分析
STEP3:
请地毯式地做数据表的双维度分析
STEP4:
请地毯式地做数据表的三维度交叉分析
STEP5:
那结合你盘点的数据，这个报告如何写，我最后需要做科技感十足可视化html文件，文件目录中有参考生成样式，参考样式按要求匹配相应数据的地方采用多样化的可视化图表，多标签页归类分析、且自适应窗口，按当前日期获取生成我提供一个另外报告的提示词
# 非主材采购申请多维度数据分析报告（含问题分析+降本改进点）
## 角色与核心目标
扮演资深数据分析师+企业采购管理专家，基于你盘点的数据，这个报告如何写，我需要做科技感十足可视化html文件。核心目标：1）清晰呈现采购数据现状；2）精准定位采购流程、成本控制中的核心问题；3）提炼可落地的降本改进措施，优化京东阳光采购与线下采购的协同效率。
## 数据基础说明
### 1. 数据字段定义
- 核心分析字段：创建日期、采购类别、流程名、申请人、申请单位、物料名称、数量、预计总含税金额、实际下单方式（京东/线下）、特殊下单原因、备注说明
- 采购场景：非主材采购，支持京东阳光采购平台（优先）+ 线下采购（补充）两种模式
### 2. 分析前提假设
- 数据完整性：默认数据无缺失关键字段（若有缺失，需在报告中注明并基于有效数据分析）
- 金额口径：所有金额均以“预计总含税金额”为基准，不涉及实际支付金额与预计金额的差异分析（除非数据中提供实际支付金额）
- 时间范围：以数据中“创建日期”的实际跨度为分析周期（如近3个月、半年），需在报告开篇明确
## 第一部分：多维度数据分析（需数据可视化支撑）
### 1. 整体采购概况
- 分析维度：采购申请总量、总金额（累计预计总含税金额）、平均单笔金额、分析周期内的时间分布（按周/月统计申请量/金额趋势）
- 输出要求：用柱状图/折线图展示时间趋势，明确整体采购规模与波动特征
### 2. 采购方式分析（核心维度）
- 分析维度：京东采购vs线下采购的申请量占比、金额占比；两种方式的平均单笔金额对比；不同采购类别的下单方式偏好（如某类物料更倾向线下采购）
- 输出要求：用饼图展示占比，柱状图对比平均金额，表格呈现采购类别与下单方式的交叉分析结果
### 3. 采购类别与物料分析
- 分析维度：各采购类别的申请量排名、金额排名；金额TOP10的物料名称及对应申请单位、下单方式；高频率采购物料（申请次数≥X次）的分布特征
- 输出要求：用条形图展示TOP排名，表格列出高频/高金额物料详情
### 4. 申请单位与申请人分析
- 分析维度：各申请单位的采购申请量、金额排名；单笔金额超阈值（如5000元）的申请分布（按单位/申请人）；同一申请人的采购频次与金额特征
- 输出要求：用热力图/条形图展示单位排名，表格列出大额申请明细
### 5. 特殊下单原因分析
- 分析维度：线下采购的特殊下单原因分布（如“京东无货”“紧急采购”“价格更低”等）；不同原因对应的申请量、金额占比；高频特殊原因的合理性评估
- 输出要求：用饼图展示原因分布，表格关联原因与金额/类别数据
## 第二部分：问题分析（基于数据分析结果，聚焦成本与效率）
### 1. 采购方式相关问题
- 核心方向：线下采购占比是否过高？是否存在“可京东采购却选择线下”的情况？线下采购的平均单笔金额是否显著高于京东（可能存在溢价）？
- 问题挖掘：特殊下单原因中是否有不合理项（如“价格更低”但无实际比价依据、“紧急采购”频繁导致流程简化）？京东采购的物料覆盖率是否不足，导致线下采购被动增加？
### 2. 成本控制相关问题
- 核心方向：是否存在重复采购（同一物料短时间内多单位/多人申请）？高金额非主材采购是否缺乏集中议价机制？单笔金额较小（如≤100元）的高频采购是否存在分散下单导致的物流成本浪费？
- 问题挖掘：不同申请单位对同一物料的采购价格是否存在差异（需结合备注说明）？线下采购是否缺乏价格管控，导致成本高于京东同款？
### 3. 流程与效率相关问题
- 核心方向：采购流程名对应的申请量/金额分布是否均衡（是否存在某类流程冗余或缺失）？特殊下单原因的审批是否严格（如无明确理由的线下采购占比）？
- 问题挖掘：紧急采购的频次是否过高，反映出采购计划的缺失？申请人是否存在不熟悉京东平台物料库，导致不必要的线下采购？
### 4. 数据质量相关问题（可选）
- 核心方向：备注说明是否完整（如线下采购无特殊原因说明）？物料名称是否存在不规范（如同一物料不同命名）导致的统计偏差？
## 第三部分：改进点提炼（聚焦降本，可落地、可量化）
### 1. 优化采购方式结构（核心降本方向）
- 改进措施：
1. 提升京东采购覆盖率：针对高频线下采购物料，协调京东平台补充库存或引入同款供应商，减少“无货”导致的线下采购；
2. 规范线下采购审批：制定线下采购的严格准入标准（如仅“京东无货”“紧急采购”“金额低于京东30%以上”可审批），要求提供比价单或紧急情况说明；
3. 限制小额线下采购：单笔金额≤X元的非紧急采购，强制要求通过京东平台下单，集中配送降低物流成本。
- 降本预期：预计线下采购占比降低X%，因京东批量采购折扣+避免线下溢价，单次采购成本平均降低Y%。
### 2. 强化集中采购与议价（规模降本）
- 改进措施：
1. 对高频、高金额物料实施集中采购：按季度/月度统计各单位需求，由采购部门统一在京东平台批量下单，争取更高折扣；
2. 针对线下采购占比高的采购类别，引入2-3家线下供应商比价，建立合格供应商库，避免单一供应商溢价；
3. 建立非主材采购价格数据库，定期更新京东平台与线下供应商的价格，供申请人参考比价。
- 降本预期：集中采购物料成本降低X%-Y%，线下采购比价后成本平均降低Z%。
### 3. 优化采购流程与计划（隐性降本）
- 改进措施：
1. 减少重复采购：建立非主材采购共享查询平台，申请人下单前可查询近期是否有其他单位采购同款物料，支持拼单或调拨；
2. 降低紧急采购频次：要求各单位提前制定月度/季度非主材采购计划，避免临时紧急采购导致的成本增加（如加急配送费）；
3. 加强京东平台使用培训：针对申请人开展京东物料库查询、下单流程培训，减少因操作不熟悉导致的线下采购。
- 降本预期：重复采购减少X%，紧急采购频次降低Y%，隐性物流/人力成本节省Z元/年。
### 4. 数据与管控机制优化（长效保障）
- 改进措施：
1. 完善数据录入规范：要求线下采购必须填写明确的特殊下单原因及比价依据，备注说明需完整；
2. 建立采购数据分析常态化机制：每月生成非主材采购分析报告，跟踪降本措施执行效果，及时调整优化；
3. 设定降本KPI：针对各申请单位设定京东采购覆盖率、线下采购占比等KPI，与部门绩效挂钩。
- 降本预期：数据质量提升后，采购决策更精准，长效降本X%/年。
## 报告输出要求
1. 结构清晰：严格按“数据分析→问题分析→改进点提炼”三部分撰写，每部分下设二级标题，逻辑连贯；
2. 数据支撑：所有问题分析需对应具体数据（如“线下采购金额占比达45%，高于行业平均水平20%”），改进点需明确降本逻辑与预期目标；
3. 可视化建议：明确每个分析维度对应的图表类型，标注数据来源（如“数据来源于XX系统导出Excel，分析周期：202X年X月-X月”）；
4. 语言简洁：专业但不晦涩，避免过多技术术语，重点突出核心数据、关键问题与可落地措施；
5. 格式规范：正文采用小四字体、1.5倍行距，图表需标注标题、单位，关键数据用加粗突出。
## 执行说明
1. 若Excel数据中存在缺失字段或异常值（如金额为0、创建日期格式错误），需在报告开篇“数据说明”部分注明，并说明处理方式（如剔除异常值、补充合理假设）；
2. 分析过程中需结合企业非主材采购的实际场景（如行业特性、采购规模），避免泛泛而谈；
3. 改进点需区分优先级，可标注“优先执行”“中长期推进”，方便落地实施。